Cluster-api: clusterctl init should ignore pre-releases

Created on 30 Jul 2020  路  7Comments  路  Source: kubernetes-sigs/cluster-api

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

areclusterctl kinfeature lifecyclactive

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-prereleases type of flag if we wanted to.

All 7 comments

馃憤 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.

Was this page helpful?
0 / 5 - 0 ratings