clusterctl should block its usage across minor versions of CAPI

wfernandes commented 4 years ago

User Story

As a user I would like to ensure that I'm using the appropriate version of clusterctl with a management cluster because I do not want to have unexpected side effects when performing cluster operations.

Detailed Description

If we have a v1alpha3 management cluster (which may have been created by clusterctl-v1a3 init), then we should be blocked from using a clusterctl cli from a newer minor release (e.g. clusterctl-v1a4 init -i <infra>). However, we still want upgrades to work. clusterctl-v1a3 --> clusterctl from a v0.3.x release clusterctl-v1a4 --> clusterctl from a v0.4.x release

Anything else you would like to add:

See last discussion topic in meeting notes from Aug 26, 2020.
See https://github.com/kubernetes-sigs/cluster-api/pull/3484#discussion_r473115371 for other relevant discussion

Other questions to consider:

Q: From the meeting notes, when we say clusterctl-v1a4 cannot be used with clusterctl-v1a3, what do we mean by that? Do we mean that a management cluster that has been initialized by clusterctl-v1a3 cannot be operated on by clusterctl-v1a4 (except for upgrades)?
Q: For n-Core multi-tenancy, are we expecting users to have two versions ofclusterctl's installed if there are two versions of management clusters installed in separate namespaces on the same k8s cluster?
Q: Regarding provider metadata, it seems this is a solution that decoupled the version of clusterctl vs. the management cluster contract. Do we need to have an option that allows upgrading across contract versions based on the version of clusterctl used?

/kind feature /area clusterctl

fabriziopandini commented 4 years ago

+1 to this IMO the most tricky part is that in a multitenancy scenario a management cluster could be both v1alpha3 and v1apha4 at the same time. Happy to brainstorm about how to get this addressed

vincepri commented 4 years ago

/milestone v0.4.0

vincepri commented 4 years ago

/priority important-soon

One clarification, clusterctl shouldn't support environments running multiple different versions of the controllers going forward

wfernandes commented 4 years ago

Yes, moving forward this may look a little different. We may have to ensure that there is consistency between the clusterctl CLI and the management cluster operator versions rather than the version of the management cluster itself.

fejta-bot commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

vincepri commented 3 years ago

/lifecycle frozen

fabriziopandini commented 3 years ago

/close This has been fixed by the work in preparation for v1alpha3 --> v1alpha4 upgrades

k8s-ci-robot commented 3 years ago

@fabriziopandini: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/cluster-api/issues/3534#issuecomment-825150429): >/close >This has been fixed by the work in preparation for v1alpha3 --> v1alpha4 upgrades Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

kubernetes-sigs / cluster-api

clusterctl should block its usage across minor versions of CAPI #3534