operator-framework/operator-sdk

Meta Issue for k8s 1.29 bump

Neo2308 opened this issue · 6 comments

Meta Issue for k8s 1.29 bump

In order to bump Operator SDK to support Kubernetes 1.29 there are a few dependencies we rely on making the bump first.
This issue is meant to help track all dependencies and the status of their bumps.

Order of dependency bumps

Step 1: upgrade controller-runtime, controller-tools, helm, and operator-framework/operator-manifest-tools(can be done in parallel)

Step 2: upgrade operator-framework/api and sigs.k8s.io/kubebuilder-declarative-pattern (can be done immediately after controller-runtime)

Step 3.1: upgrade operator-framework/operator-registry and operator-framework/operator-lib (can be done immediately after operator-framework/api)

Step 3.2: upgrade kubebuilder (blocked until kubebuilder-declarative-pattern is bumped)

Step 4: upgrade operator-framework plugins

Step 5: upgrade operator-framework/operator-sdk dependencies

  • Bump Ginkgo/v2 and Kubebuilder 1.29 (#6736)
  • Bump SDK to use k8s 1.29 (#6736)

Keeping this open for the community. Please feel free to pick up any other issues. Any contribution would be appreciated :)

We need to add the ansible plugin to the list as well.

@varshaprasad96 can you confirm that we no longer need to track the update in sigs.k8s.io/kubebuilder-declarative-pattern for these meta issues since kubernetes-sigs/kubebuilder#3395 is done?

(Removed the Bump envtest to 1.29 based on comments in #6554)

Can also helm be upgraded as part of this issue?
In order to solve the following security violability:
GHSA-r53h-jv2g-vpx6

Thanks!

The CVE for the above vulnerability is CVE-2024-26147 (I was having trouble searching for this issue based on the CVE)

@Neo2308 I'll try to cut a release of the ansilbe-plugin on monday, since the rest of this week is a holiday.