Upgrade dependencies #200
Upgrade dependencies #200
Conversation
This fixes the dependabot alert We have to downgrade logr or else we get a bunch of dependency conflicts. We'll need to remove that replace directive when we upgrade the k8s verison we base on. Signed-off-by: Will Beason <willbeason@google.com>
Signed-off-by: Will Beason <willbeason@google.com>
Signed-off-by: Will Beason <willbeason@google.com>
Signed-off-by: Will Beason <willbeason@google.com>
Signed-off-by: Will Beason <willbeason@google.com>
This gets us to the latest stable k8s libraries. Signed-off-by: Will Beason <willbeason@google.com>
Signed-off-by: Will Beason <willbeason@google.com>
|
I was able to upgrade to k8s 0.23.3 libraries, which gets us past the logr upgrade. Open Telemetry has a habit of its dependencies getting out of sync, so I've added replace directives to keep them in lockstep. The go mod command isn't able to resolve these on its own. As far as I can tell, we need to skip k8s 0.22.x since the Open Telemetry libraries are inconsistent across our dependencies. |
Signed-off-by: Will Beason <willbeason@google.com>
No longer compatible with 1.16 with library upgrades Signed-off-by: Will Beason <willbeason@google.com>
Signed-off-by: Will Beason <willbeason@google.com>
Signed-off-by: Will Beason <willbeason@google.com>
|
The gatekeeper failure is expected - it needs to pin the otel dependencies in order for Go to resolve dependencies correctly. |
| k8s.io/apimachinery v0.23.3 | ||
| k8s.io/client-go v0.23.3 | ||
| k8s.io/utils v0.0.0-20211116205334-6203023598ed | ||
| sigs.k8s.io/controller-runtime v0.11.1 |
There was a problem hiding this comment.
how does this impact the controller-runtime we use in gatekeeper? and will it work with the dynamiccache fork of controller-runtime https://github.com/open-policy-agent/gatekeeper/tree/master/third_party/sigs.k8s.io/controller-runtime?
There was a problem hiding this comment.
I'll test this locally to see if this upgrade breaks Gatekeeper.
There was a problem hiding this comment.
I've tested locally, and the upgrade works without impacting Gatekeeper. The dynamiccache fork works correctly.
There was a problem hiding this comment.
Would we need to upgrade our fork? @shomron
There was a problem hiding this comment.
Nope - we don't need to. I tested the upgrade and we don't have to modify our fork.
The big one here is upgrading opa to v0.37.2 to fix the security vulnerability.