cluster-api: clusterctl config repositories point to invalid URLs

What steps did you take and what happened: Run the following:

clusterctl config repositories
NAME          TYPE                     URL
cluster-api   CoreProvider             https://github.com/kubernetes-sigs/cluster-api/releases/latest/core-components.yaml
kubeadm       BootstrapProvider        https://github.com/kubernetes-sigs/cluster-api/releases/latest/bootstrap-components.yaml
kubeadm       ControlPlaneProvider     https://github.com/kubernetes-sigs/cluster-api/releases/latest/control-plane-components.yaml
aws           InfrastructureProvider   https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases/latest/infrastructure-components.yaml
azure         InfrastructureProvider   https://github.com/kubernetes-sigs/cluster-api-provider-azure/releases/latest/infrastructure-components.yaml
metal3        InfrastructureProvider   https://github.com/metal3-io/cluster-api-provider-metal3/releases/latest/infrastructure-components.yaml
openstack     InfrastructureProvider   https://github.com/kubernetes-sigs/cluster-api-provider-openstack/releases/latest/infrastructure-components.yaml
vsphere       InfrastructureProvider   https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/releases/latest/infrastructure-components.yaml

Pick any of the repositories and you will get a ‘Not Found’ message:

curl https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/releases/latest/infrastructure-components.yaml
Not Found

What did you expect to happen:

The repositories will reference valid YAML repositories AND the specific version of clusterctl should be used in the repository URL (not latest).

Anything else you would like to add:

N/A

Environment:

Cluster-api version: clusterctl version: &version.Info{Major:“0”, Minor:“3”, GitVersion:“v0.3.3”, GitCommit:“ecff70af1b839c4086335234d88b1b8c00c3383c”, GitTreeState:“clean”, BuildDate:“2020-03-27T22:25:55Z”, GoVersion:“go1.13.8”, Compiler:“gc”, Platform:“darwin/amd64”}
Minikube/KIND version: N/A
Kubernetes version: (use kubectl version): N/A
OS (e.g. from /etc/os-release): MacOS

/kind bug

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (13 by maintainers)

Most upvoted comments

How the URL should be interpreted to determine what is the base repository vs what is latest/version depends on the type of repository (Github vs FileSystem).

Instantiating those repository objects might be overkilling for the current command output, but if instead, we decide to redesign the output and show available versions this could make sense (there is also an issue for this https://github.com/kubernetes-sigs/cluster-api/issues/2171). On the backside, we should also consider that a scan of all the repositories might consume the full free quota of the github APIs in a single shot…

fabriziopandini on Mar 31, 2020

@wfernandes +1 to the idea What about moving the file name to a separated column? This will make clear the difference between the three provider that are reading from the cluster API repository. Also please make sure the spot mechanism works for local repository as well.

fabriziopandini on Apr 10, 2020

@vincepri yes, sorry, I forgot to notate what the correct URL should be. Was thinking it also should reference the correct version that is associated with the currently installed clusterctl binary (as opposed to latest), but perhaps that is taking it a bit too far.

scottd018 on Mar 31, 2020