search

kubernetes-sigs / cluster-api

Home for Cluster API, a subproject of sig-cluster-lifecycle
https://cluster-api.sigs.k8s.io
Apache License 2.0
3.57k stars 1.31k forks source link

clusterctl init should ignore pre-releases #3435

Closed wfernandes closed 4 years ago

wfernandes commented 4 years ago

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

ncdc commented 4 years ago

👍 from me, and I'd like to wait to do anything here until @fabriziopandini has a chance to provide his thoughts.

vincepri commented 4 years ago

/milestone v0.3.x

fabriziopandini commented 4 years ago

I'm +1 in having clusterctl to ignore pre-releases when resolving latest

vincepri commented 4 years ago

/milestone v0.3.9

wfernandes commented 4 years ago

/assign /lifecycle active

wfernandes commented 4 years ago

@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.

ncdc commented 4 years ago

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.