🌱 Update to Kubernetes v1.33.2 and cluster-api v1.11

[pierreprinetti]

What this PR does / why we need it:

Is it time for a kube bump yet?

Notes for the reviewers:

• Use Go v1.24.4
• Rename "sigs.k8s.io/cluster-api/hack/tools/release" to "sigs.k8s.io/cluster-api/hack/tools/release/notes"
• make generate
• Add one API rule violation

TODOs:

• [x] squashed commits
• if necessary:
  • [ ] includes documentation
  • [ ] adds unit tests

[netlify[bot]]

❌ Deploy Preview for kubernetes-sigs-cluster-api-openstack failed. Why did it fail? →

Name	Link
🔨 Latest commit	7130f9e6ca76a046361e414caab4f9cf79e86ec2
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-cluster-api-openstack/deploys/68669a1bc8c2f20008e22f72

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign neolit123 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[pierreprinetti]

/hold

cluster-api v1.10.3 still needs apimachinery v0.32.3. The bump has been made on the main branch, and we have to wait for them to cut a release.

[pierreprinetti]

Util functions in cluster-api v1.11 return v1beta2 objects. Do we expect to use v1beta2 objects in the CAPO releases that are meant for k8s v1.33?

CC @mdbooth @lentzi90

[mdbooth]

Util functions in cluster-api v1.11 return v1beta2 objects. Do we expect to use v1beta2 objects in the CAPO releases that are meant for k8s v1.33?

Sounds like this is going to be the path of least resistance. Do you think it's worth a separate PR to bump to v1beta2 objects?

[pierreprinetti]

Util functions in cluster-api v1.11 return v1beta2 objects. Do we expect to use v1beta2 objects in the CAPO releases that are meant for k8s v1.33?

Sounds like this is going to be the path of least resistance. Do you think it's worth a separate PR to bump to v1beta2 objects?

It looks like v1beta2 was introduced in capi v1.11: https://github.com/kubernetes-sigs/cluster-api/tree/v1.10.3/api

[pierreprinetti]

[EDIT] this was a long question that is not necessary any more

[pierreprinetti]

@mdbooth In the end I think that the best solution would be for cluster-api to continue to provide the v1beta1 util functions we need. I am proposing it here: https://github.com/kubernetes-sigs/cluster-api/pull/12441

This PR temporarily uses my fork of cluster-api to test the potential result.

[k8s-ci-robot]

@pierreprinetti: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-cluster-api-provider-openstack-build	7130f9e6ca76a046361e414caab4f9cf79e86ec2	link	true	/test pull-cluster-api-provider-openstack-build
pull-cluster-api-provider-openstack-test	7130f9e6ca76a046361e414caab4f9cf79e86ec2	link	true	/test pull-cluster-api-provider-openstack-test
pull-cluster-api-provider-openstack-e2e-test	7130f9e6ca76a046361e414caab4f9cf79e86ec2	link	true	/test pull-cluster-api-provider-openstack-e2e-test

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[pierreprinetti]

test/e2e/shared/suite.go:188:56: cannot use OpenStackLogCollector{…} (value of struct type OpenStackLogCollector) as framework.ClusterLogCollector value in argument to framework.WithMachineLogCollector: OpenStackLogCollector does not implement framework.ClusterLogCollector (wrong type for method CollectInfrastructureLogs)
		have CollectInfrastructureLogs(context.Context, "sigs.k8s.io/controller-runtime/pkg/client".Client, *"sigs.k8s.io/cluster-api/api/core/v1beta1".Cluster, string) error
		want CollectInfrastructureLogs(context.Context, "sigs.k8s.io/controller-runtime/pkg/client".Client, *"sigs.k8s.io/cluster-api/api/core/v1beta2".Cluster, string) error 

I’m starting to question what I committed to.

[mdbooth]

The problem is we're trying to call framework.WithMachineLogCollector from CAPI , which takes an argument which implements the ClusterLogCollector from CAPI. There's only a v1beta2 version of this interface, and of framework.WithMachineLogCollector. I have a horrible suspicion that at the end of this road is a complete re-implementation of the CAPI test framework 😬

[pierreprinetti]

@mdbooth What do you think about @fabriziopandini's comment in the cluster-api PR?

Shall we move to v1beta2 manifests (based on cluster-api v1beta2), move controllers to v1beta2 and implement conversion to support v1beta1?

[mdbooth]

@mdbooth What do you think about @fabriziopandini's comment in the cluster-api PR?

Shall we move to v1beta2 manifests (based on cluster-api v1beta2), move controllers to v1beta2 and implement conversion to support v1beta1?

I personally think this is the path of least resistance. If I'm honest it's what I originally assumed you were doing here.

I don't think we'll need any conversions until we update the OpenStack resources (OpenStackMachine, OpenStackCluster) to the v1beta2 contract. That is: CAPO controllers will consume CAPI v1beta2 objects, but will themselves continue to publish infra objects conforming to CAPI v1beta1. We've been set a deadline of August next year to move to v1beta2, though, so we should probably get on that.

[k8s-ci-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[pierreprinetti]

Closing in favour of #2640