User Story
As an operator I would like to ignore pre-releases when I run clusterctl init in order to avoid unintended side-effects when setting up my management cluster.
Detailed Description
At the time of writing this issue, CAPV released v0.7.0-alpha.0. Before this was released, we merged https://github.com/kubernetes-sigs/cluster-api/pull/3412 to include the metadata contract for future v0.7.0 releases.
Then when users installed the latest clusterctl and ran clusterctl init --infrastructure vsphere without specifying a version number it pulled the "latest" release which was v0.7.0-alpha.0. Instead of installing a pre-release, we should default to the latest stable release version (e.g. v0.6.6).
If users want to install a pre-release version, they can run clusterctl init --infrastructure vsphere:v0.7.0-alpha.0.
Anything else you would like to add:
For context, https://github.com/kubernetes-sigs/cluster-api/issues/3418
/kind feature
/area clusterctl
馃憤 from me, and I'd like to wait to do anything here until @fabriziopandini has a chance to provide his thoughts.
/milestone v0.3.x
I'm +1 in having clusterctl to ignore pre-releases when resolving latest
/milestone v0.3.9
/assign
/lifecycle active
@vincepri @ncdc @fabriziopandini Do we want to allow users to upgrade to pre-release versions?
That is, when users run
$ clusterctl upgrade plan
Checking new release availability...
Management group: capi-system/cluster-api, latest release available for the v1alpha3 API Version of Cluster API (contract):
NAME NAMESPACE TYPE CURRENT VERSION NEXT VERSION
bootstrap-kubeadm capi-kubeadm-bootstrap-system BootstrapProvider v0.3.8 Already up to date
control-plane-kubeadm capi-kubeadm-control-plane-system ControlPlaneProvider v0.3.8 Already up to date
cluster-api capi-system CoreProvider v0.3.8 Already up to date
infrastructure-vsphere capv-system InfrastructureProvider v0.6.6 v0.7.0-alpha.0
You can now apply the upgrade by executing the following command:
upgrade apply --management-group capi-system/cluster-api --contract v1alpha3
Do we want to show them that there is v0.7.0-alpha.0?
Because if they run clusterctl upgrade apply --management-group capi-system/cluster-api --contract v1alpha3, it currently installs the pre-release version.
I'd say we should require you to explicitly ask for prereleases by specifying the exact version you want for now. In the future, we could consider adding a --include-prereleases type of flag if we wanted to.
Most helpful comment
I'd say we should require you to explicitly ask for prereleases by specifying the exact version you want for now. In the future, we could consider adding a
--include-prereleasestype of flag if we wanted to.