Meta Issue for k8s 1.32 bump

[acornett21]

Meta Issue for k8s 1.32 bump

In order to bump Operator SDK to support Kubernetes 1.32 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)

• sigs.k8s.io/controller-runtime (https://github.com/kubernetes-sigs/controller-runtime/releases/tag/v0.20.4)
• sigs.k8s.io/controller-tools (https://github.com/kubernetes-sigs/controller-tools/releases/tag/v0.17.3)
• operator-framework/operator-manifest-tools (https://github.com/operator-framework/operator-manifest-tools/releases/tag/v0.9.0)

Step 2: upgrade operator-framework/api (can be done immediately after controller-runtime & controller-tools)

• operator-framework/api (https://github.com/operator-framework/api/releases/tag/v0.30.0)

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

• operator-framework/operator-registry (https://github.com/operator-framework/operator-registry/releases/tag/v1.51.0)
• operator-framework/operator-lib (https://github.com/operator-framework/operator-lib/releases/tag/v0.18.0)

Step 3.2: upgrade kubebuilder

• sigs.k8s.io/kubebuilder/v4 (https://github.com/kubernetes-sigs/kubebuilder/releases/tag/v4.5.2)

Step 4: upgrade operator-framework plugins

• operator-framework/ansible-operator-plugins (https://github.com/operator-framework/ansible-operator-plugins/releases/tag/v1.38.0)

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

• Bump Ginkgo/v2 and Kubebuilder 1.32
• Bump SDK to use k8s 1.32 (⚠️ Upgrade kubebuilder scaffold from v4.2.0 to v4.5.2 #6928)

[acornett21]

@camilamacedo86 Do you think the lift will be excessive to go from kubebuilder v4.2.0 -> 4.5.2? Or would you recommend another version to get k8s 1.32 from?

[camilamacedo86]

I recommend upgrading to the latest release directly. This ensures that Operator-SDK end-users receive all the latest bug fixes and enhancements. Moreover, that we do this effort just once here.

As far I remember, in this jump, the only "breaking change" affects those who are using webhooks, due to a breaking change introduced in controller-runtime. You can read more about it here: Kubebuilder v4.5.0 Release Notes.

From the Operator-SDK maintainers perspective, the main efforts to do the jump involved mainly are:

• Bumping Kubebuilder
• Regenrate the samples under the testdata
• We might need to fix the testdata generations/find and replaces according to the changes
• Comparing the testdata samples from the PR with the current state in master, in order to compile the complete release notes. This comparison is expected to be the most time-intensive part of the task.

[camilamacedo86]

Hi @acornett21

I started to do already, see: #6928
It is scaffolding everything, but is missing the creation of the release notes.

[acornett21]

• Relates: updating dependencies to latest allowable version(s) #6951

[acornett21]

• Relates: fixing scafolding after kubebuilder update ansible-operator-plugins#146

[acornett21]

Closing this since this was released yesterday
https://github.com/operator-framework/operator-sdk/releases/tag/v1.40.0