🐛 Revert v1beta2 contract

[lentzi90]

What this PR does / why we need it:

We have not fully implemented the contract yet, so we were wrong to advertise it. Sticking to v1beta1 until we are ready for real.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

1. Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

TODOs:

• squashed commits
• if necessary:
  • includes documentation
  • adds unit tests

/hold

[netlify]

✅ Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!

Name	Link
🔨 Latest commit	85ae706
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-cluster-api-openstack/deploys/693809bd021ba10007cae67b
😎 Deploy Preview	https://deploy-preview-2883--kubernetes-sigs-cluster-api-openstack.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[lentzi90]

/test pull-cluster-api-provider-openstack-e2e-full-test

[lentzi90]

/test pull-cluster-api-provider-openstack-e2e-full-test

[lentzi90]

Cleaned up log from the upgrade:

When testing clusterctl upgrades for CAPO (v0.13=>current) and ORC (v1.0.2=>current)[clusterctl-upgrade] Should create a management cluster and then upgrade all the providers
/root/go/pkg/mod/sigs.k8s.io/cluster-api/[email protected]/e2e/clusterctl_upgrade.go:265
 > Enter [It] Should create a management cluster and then upgrade all the providers @ 12/08/25 07:36:44.385
 STEP: Creating a kind cluster to be used as a new management cluster @ 12/08/25 07:36:44.385
 INFO: Creating a kind cluster with name "clusterctl-upgrade-management-z84t3g"
Creating cluster "clusterctl-upgrade-management-z84t3g" ...
 STEP: Turning the new cluster into a management cluster with older versions of providers @ 12/08/25 07:36:56.674
 STEP: Downloading clusterctl binary from https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.11.0/clusterctl-linux-amd64 @ 12/08/25 07:36:56.674
 STEP: Initializing the new management cluster with older versions of providers @ 12/08/25 07:36:57.384
 INFO: clusterctl init --config /logs/artifacts/repository/clusterctl-config.yaml --kubeconfig /tmp/e2e-kind3178366286 --wait-providers --core cluster-api:v1.11.0 --bootstrap kubeadm:v1.11.0 --control-plane kubeadm:v1.11.0 --infrastructure openstack:v0.13.1 --runtime-extension openstack-resource-controller:v1.0.2
 INFO: Waiting for provider controllers to be running
 STEP: Waiting for deployment capi-kubeadm-bootstrap-system/capi-kubeadm-bootstrap-controller-manager to be available @ 12/08/25 07:37:38.043
 STEP: Waiting for deployment capi-kubeadm-control-plane-system/capi-kubeadm-control-plane-controller-manager to be available @ 12/08/25 07:37:38.153
 STEP: Waiting for deployment capi-system/capi-controller-manager to be available @ 12/08/25 07:37:38.158
 STEP: Waiting for deployment capo-system/capo-controller-manager to be available @ 12/08/25 07:37:38.162
 STEP: Waiting for deployment orc-system/orc-controller-manager to be available @ 12/08/25 07:37:38.447
 STEP: THE MANAGEMENT CLUSTER WITH THE OLDER VERSION OF PROVIDERS IS UP&RUNNING! @ 12/08/25 07:37:39.046
 STEP: Creating a namespace for hosting the clusterctl-upgrade test workload cluster @ 12/08/25 07:37:39.046
 INFO: Creating namespace clusterctl-upgrade
 INFO: Creating event watcher for namespace "clusterctl-upgrade"
 STEP: Creating a test workload cluster @ 12/08/25 07:37:39.051
 INFO: Creating the workload cluster with name "clusterctl-upgrade-workload-j890t1" using the "(default)" template (Kubernetes v1.34.2, 1 control-plane machines, 1 worker machines)
 INFO: Getting the cluster template yaml
 INFO: clusterctl generate cluster clusterctl-upgrade-workload-j890t1 --infrastructure  --kubernetes-version v1.34.2 --worker-machine-count 1 --flavor  --target-namespace clusterctl-upgrade --config /logs/artifacts/repository/clusterctl-config.yaml --kubeconfig /tmp/e2e-kind3178366286 --control-plane-machine-count 1
 INFO: Applying the cluster template yaml to the cluster in dry-run
 INFO: Applying the cluster template yaml to the cluster
 STEP: Calculating expected MachineDeployment and MachinePool Machine and Node counts @ 12/08/25 07:38:59.645
 STEP: Expect 2 Machines and 0 MachinePool replicas to exist @ 12/08/25 07:38:59.656
 STEP: Waiting for the machines to exist @ 12/08/25 07:38:59.656
 STEP: Waiting for MachinePool to be ready with correct number of replicas @ 12/08/25 07:41:19.746
 STEP: THE MANAGEMENT CLUSTER WITH OLDER VERSION OF PROVIDERS WORKS! @ 12/08/25 07:41:19.75
 STEP: [0] Starting upgrade @ 12/08/25 07:41:19.75
 STEP: [0] Upgrading providers to the latest version available @ 12/08/25 07:41:19.755
 INFO: clusterctl upgrade apply --config /logs/artifacts/repository/clusterctl-config.yaml --kubeconfig /tmp/e2e-kind3178366286 --wait-providers --contract v1beta2
 INFO: Waiting for provider controllers to be running
 STEP: Waiting for deployment capi-kubeadm-bootstrap-system/capi-kubeadm-bootstrap-controller-manager to be available @ 12/08/25 07:41:57.44
 STEP: Waiting for deployment capi-kubeadm-control-plane-system/capi-kubeadm-control-plane-controller-manager to be available @ 12/08/25 07:41:57.444
 STEP: Waiting for deployment capi-system/capi-controller-manager to be available @ 12/08/25 07:41:57.447
 STEP: Waiting for deployment capo-system/capo-controller-manager to be available @ 12/08/25 07:41:57.45
 STEP: Waiting for deployment orc-system/orc-controller-manager to be available @ 12/08/25 07:41:57.453
 STEP: [0] THE MANAGEMENT CLUSTER WAS SUCCESSFULLY UPGRADED! @ 12/08/25 07:41:57.455
 STEP: Waiting for cluster to enter the provisioned phase @ 12/08/25 07:41:57.466
 STEP: [0] Waiting for three minutes before checking if an unexpected rollout happened @ 12/08/25 07:41:57.581
 STEP: [0] Verifing there are no unexpected rollouts @ 12/08/25 07:44:57.586
 STEP: [0] Scale MachineDeployment to ensure the providers work @ 12/08/25 07:44:57.598
 INFO: Scaling machine deployment clusterctl-upgrade/clusterctl-upgrade-workload-j890t1-md-0 from 1 to 2 replicas
 INFO: Waiting for correct number of replicas to exist
 INFO: Scaling machine deployment clusterctl-upgrade/clusterctl-upgrade-workload-j890t1-md-0 from 2 to 1 replicas
 INFO: Waiting for correct number of replicas to exist
 STEP: [0] Checking that resourceVersions are stable @ 12/08/25 07:46:17.973
 STEP: Check resourceVersions are stable @ 12/08/25 07:46:17.973
 STEP: Check resourceVersions remain stable @ 12/08/25 07:46:33.761
 STEP: [0] Verify Cluster Available condition is true @ 12/08/25 07:48:33.761
 STEP: [0] Verify Machines Ready condition is true @ 12/08/25 07:48:33.766
 STEP: [0] Verify client-side SSA still works @ 12/08/25 07:48:33.771
 STEP: [0] THE UPGRADED MANAGEMENT CLUSTER WORKS! @ 12/08/25 07:48:33.803
 STEP: PASSED! @ 12/08/25 07:48:33.803 

[lentzi90]

I have also verified the versions used in the test by checking container logs. CAPO is going from v0.13.1 to "" (main).
CAPI is going from v1.11.0 to v1.11.3.
I am not fully convinced this tests the contract change though. We set the contract in the e2e config, but we also set it in the metadata, and that now has the v1beta1 value for v0.13.1. I'll see if I can make that also "authentic".

[lentzi90]

/test pull-cluster-api-provider-openstack-e2e-full-test

[lentzi90]

Most likely a temporary failure. This test should not have been affected by my latest push.
/test pull-cluster-api-provider-openstack-e2e-test

[lentzi90]

/test pull-cluster-api-provider-openstack-e2e-full-test

[lentzi90]

Now I am convinced that the upgrade is properly checking v0.13.1 -> v0.13.99 (main) with v1beta2 in the metadata for the first and v1beta1 in the second.

[lentzi90]

/hold cancel

[lentzi90]

/approve
/cc @bnallapeta

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lentzi90

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lentzi90]

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

[bnallapeta]

Looks good. But could we please rename the folder mistake to either errata or legacy or overrides?
I lean towards errata as that's quite commonly used.

[lentzi90]

Yeah that makes sense. I'll update!

[lentzi90]

/test pull-cluster-api-provider-openstack-e2e-full-test

[bnallapeta]

/lgtm

[lentzi90]

/cherry-pick release-0.13

[k8s-infra-cherrypick-robot]

@lentzi90: #2883 failed to apply on top of branch "release-0.13":

Applying: Revert v1beta2 contract
Using index info to reconstruct a base tree...
M	test/e2e/data/e2e_conf.yaml
Falling back to patching base and 3-way merge...
Auto-merging test/e2e/data/e2e_conf.yaml
CONFLICT (content): Merge conflict in test/e2e/data/e2e_conf.yaml
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Revert v1beta2 contract

In response to this:

/cherry-pick release-0.13

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.