clusterctl v1beta1 should allow upgrades starting from v1alpha3 #5269
Labels
area/clusterctl
Issues or PRs related to clusterctl
kind/feature
Categorizes issue or PR as related to a new feature.
kind/release-blocking
Issues or PRs that need to be closed before the next CAPI release
Milestone
Detailed Description
Considering the v1beta1 does not introduces breaking changes from v1alpha4, and that we want to allow a smooth migration towards v1beta1, then clusterctl v1beta1 should allow upgrades starting from v1alpha3
It is also required to have v1alpha3 --> v1beta1 and v1alpha4 --> v1beta1 (one of those is already there, but not working after breaking changes for v1beta1)
Anything else you would like to add:
The change requires to add v1alpha3 and v1alpha4 to allowed contracts in
cluster-api/cmd/clusterctl/client/upgrade.go
Lines 55 to 58 in d9db880
same for upgrade apply.
The E2E requires a dedicated prow job similar to https://github.com/kubernetes/test-infra/blob/f234f533b3e2ff5694e35b7a0c4466b4c7292042/config/jobs/kubernetes-sigs/cluster-api/cluster-api-periodics-main.yaml#L25-L59
But with:
Most probably, also
cluster-api/test/e2e/clusterctl_upgrade.go
Lines 162 to 165 in 7084de3
/kind feature
The text was updated successfully, but these errors were encountered: