Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clusterctl v1beta1 should allow upgrades starting from v1alpha3 #5269

Closed
fabriziopandini opened this issue Sep 20, 2021 · 3 comments · Fixed by #5271
Closed

clusterctl v1beta1 should allow upgrades starting from v1alpha3 #5269

fabriziopandini opened this issue Sep 20, 2021 · 3 comments · Fixed by #5271
Assignees
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

Comments

@fabriziopandini
Copy link
Member

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

// Ensure this command only runs against management clusters with the current Cluster API contract (default) or the previous one.
if err := clusterClient.ProviderInventory().CheckCAPIContract(cluster.AllowCAPIContract{Contract: clusterv1old.GroupVersion.Version}); err != nil {
return nil, err
}

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:

  • GINKGO_FOCUS targeting clusterctl upgrades (instead of GINKGO_SKIP)
  • INIT_WITH_BINARY and INIT_WITH_KUBERNETES_VERSION

Most probably, also

CoreProvider: input.E2EConfig.GetProvidersWithOldestVersion(config.ClusterAPIProviderName)[0],
BootstrapProviders: input.E2EConfig.GetProvidersWithOldestVersion(config.KubeadmBootstrapProviderName),
ControlPlaneProviders: input.E2EConfig.GetProvidersWithOldestVersion(config.KubeadmControlPlaneProviderName),
InfrastructureProviders: input.E2EConfig.GetProvidersWithOldestVersion(input.E2EConfig.InfrastructureProviders()...),
should be changed to allow to pick a version from a specific release series (vs picking oldest).

/kind feature

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Sep 20, 2021
@fabriziopandini
Copy link
Member Author

/area clusterctl
/milestone v1.0
/kind release-blocking

@k8s-ci-robot k8s-ci-robot added this to the v1.0 milestone Sep 20, 2021
@k8s-ci-robot k8s-ci-robot added area/clusterctl Issues or PRs related to clusterctl kind/release-blocking Issues or PRs that need to be closed before the next CAPI release labels Sep 20, 2021
@fabriziopandini
Copy link
Member Author

/assign

@sbueringer
Copy link
Member

sbueringer commented Sep 21, 2021

Just fyi, testgrid looks like all tests are still consistently green.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants