operator-framework/operator-sdk

Meta Issue for k8s 1.30 bump

Neo2308 opened this issue · 5 comments

Meta Issue for k8s 1.30 bump

In order to bump Operator SDK to support Kubernetes 1.30 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 (can be done immediately after controller-runtime & controller-tools)

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

Step 4: upgrade operator-framework plugins

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

  • Bump Ginkgo/v2 and Kubebuilder 1.30
  • Bump SDK to use k8s 1.30

Copied from #6651
Removed "sigs.k8s.io/kubebuilder-declarative-pattern" based on #6651 (comment)

K8s 1.30 support for kubebuilder would be coming post the major bump in kubebuilder version.
Ref: kubernetes-sigs/kubebuilder#3622

Updated the description to remove the helm operator plugin since we are dropping hybrid support

@acornett21 wouldn't we still need to update the helm operator plugin version in the operator-sdk and hence have to update k8s/controller runtime versions in the helm repo and cut new versions?

@Neo2308 we still need to keep the helm-operator-plugin repo up to date (though since other projects depend on that that move at a quicker pace, you probably no longer need to worry about it for your needs), but it no longer needs to be a dependency of this project, since this project still contains the helm operator code. Confusing, I know, I assumed all the helm code was in the plugin repo, but it is not.