Bump versions of infrastructure providers (CAPI and CAPO)

[m-bull]

No description provided.

[sd109]

Nice work! Just a few of minor suggestions from me.

[JohnGarbutt]

Did we have to drop namespace here? Do we need namespace in the outer KubeadmControlPlane CRD?

[m-bull]

We do have to drop namespace yes - I'll go check on whether it can live on the outer KubeadmControlPlane CRD.

[m-bull]

KubeadmControlPlane expects to find its infrastructureRef resources in the same namespace as itself, so I think this is fine - its just a reference to the OpenStackMachineTemplates that the chart creates, which will end up in the same namespace as the KubeadmControlPlane.

[JohnGarbutt]

Was v1beta1 removed? I think we probabably need some bit notes in the release notes about what capi-helm-chart versions depend on, like what is the minimum version, so that the upgrades are smooth. I am hoping we can bump all the capi capo operators, nothing breaks using the older version of the helm chart, then we move to this version of the helm chart, and we are good, but I am assuming we were too late for that? (Sorry being slow getting my head around the upgrade path here).

[m-bull]

v1beta1 wasn't/isn't removed in this version, so clusters defined with that version can still be worked on by the updated CAPI - we test this by deploying a cluster at the latest tag in this repo, then upgrading to the tip of the feature branch (here: https://github.com/azimuth-cloud/capi-helm-charts/actions/runs/18321667523/job/52195259366?pr=616).

[m-bull]

Again, I think this is covered by the chart-upgrade test, but I'll test with other bits of the Azimuth stack to make sure this all works as expected.

[JohnGarbutt]

Do we need to move to v0.12.x first?

[m-bull]

I don't think so, or at least there is no requirement that I can find for that. The biggest issue would be deprecation of the v1alpha6 and v1alpha7 APIs, which we have already moved away from in #423 (https://github.com/kubernetes-sigs/cluster-api-provider-openstack/releases/tag/v0.12.0).

[sd109]

FWIW CAPI explicitly supports N+3 upgrades so I'd guess that CAPO follows something similar (or at least doesn't strictly require N+1).

[m-bull]

I think that the chart-upgrade CI test tests this path, dependencies are installed from the latest tag (so 0.11.3 in this case), and then they are bumped to the versions in this PR.

As the test passes, I think the skip-version upgrade is okay.

[JohnGarbutt]

OK, awesome work getting this green.

In my head, its not clear on the upgrade path here for Azimuth and Mangum, in terms of bumping all the operators and the helm chart version. I am guessing when we install the new operators, we must stop using the old helm chart version, and start using this version? And the operators will do the version upgrade on the CRDs that are already in the cluster "for us"?

[xin053]

Greate work, hope this PR will be merged soon.

[sd109]

FYI: kubernetes-sigs/cluster-api-provider-openstack#2883

Not sure what the implications are for this PR, but worth being aware of. There's some additional discussion about the issue in CAPI and CAPO Slack channels.

[sd109]

CAPO release v0.13.2 now reverts to v1beta1 API version apparently: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/releases/tag/v0.13.2

[m-bull]

Test that this change works with a values file from the current release: https://github.com/azimuth-cloud/capi-helm-charts/actions/runs/22406545200/job/64867882070