cluster-api: clusterctl init -i vsphere fails

What steps did you take and what happened:

$ export CLUSTERCTL_LOG_LEVEL=5
$ clusterctl init -i vsphere
Using configuration File="/Users/wfernandes/.cluster-api/clusterctl.yaml"
Installing the clusterctl inventory CRD
Creating CustomResourceDefinition="providers.clusterctl.cluster.x-k8s.io"
Fetching providers
Fetching File="core-components.yaml" Provider="cluster-api" Version="v0.3.7"
Fetching File="bootstrap-components.yaml" Provider="bootstrap-kubeadm" Version="v0.3.7"
Fetching File="control-plane-components.yaml" Provider="control-plane-kubeadm" Version="v0.3.7"
Fetching File="infrastructure-components.yaml" Provider="infrastructure-vsphere" Version="v0.7.0-alpha.0"
Fetching File="metadata.yaml" Provider="cluster-api" Version="v0.3.7"
Fetching File="metadata.yaml" Provider="bootstrap-kubeadm" Version="v0.3.7"
Fetching File="metadata.yaml" Provider="control-plane-kubeadm" Version="v0.3.7"
Fetching File="metadata.yaml" Provider="infrastructure-vsphere" Version="v0.7.0-alpha.0"
Error: invalid provider metadata: version v0.7.0-alpha.0 for the provider capv-system/infrastructure-vsphere does not match any release series
sigs.k8s.io/cluster-api/cmd/clusterctl/client/cluster.(*providerInstaller).getProviderContract
        /Users/wfernandes/workspace/cluster-api/cmd/clusterctl/client/cluster/installer.go:244
sigs.k8s.io/cluster-api/cmd/clusterctl/client/cluster.(*providerInstaller).Validate
        /Users/wfernandes/workspace/cluster-api/cmd/clusterctl/client/cluster/installer.go:200
sigs.k8s.io/cluster-api/cmd/clusterctl/client.(*clusterctlClient).Init
        /Users/wfernandes/workspace/cluster-api/cmd/clusterctl/client/init.go:103
sigs.k8s.io/cluster-api/cmd/clusterctl/cmd.runInit
        /Users/wfernandes/workspace/cluster-api/cmd/clusterctl/cmd/init.go:146
sigs.k8s.io/cluster-api/cmd/clusterctl/cmd.glob..func6
        /Users/wfernandes/workspace/cluster-api/cmd/clusterctl/cmd/init.go:88
github.com/spf13/cobra.(*Command).execute
        /Users/wfernandes/go/pkg/mod/github.com/spf13/cobra@v0.0.6/command.go:840
github.com/spf13/cobra.(*Command).ExecuteC
        /Users/wfernandes/go/pkg/mod/github.com/spf13/cobra@v0.0.6/command.go:945
github.com/spf13/cobra.(*Command).Execute
        /Users/wfernandes/go/pkg/mod/github.com/spf13/cobra@v0.0.6/command.go:885
sigs.k8s.io/cluster-api/cmd/clusterctl/cmd.Execute
        /Users/wfernandes/workspace/cluster-api/cmd/clusterctl/cmd/root.go:52
main.main
        /Users/wfernandes/workspace/cluster-api/cmd/clusterctl/main.go:25
runtime.main
        /usr/local/go/src/runtime/proc.go:203
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1357

What did you expect to happen: Expected it to work.

Anything else you would like to add: https://github.com/kubernetes-sigs/cluster-api/pull/3412 was merged in recently.

Environment:

clusterctl version: clusterctl version: &version.Info{Major:"0", Minor:"3", GitVersion:"v0.3.7", GitCommit:"846ca08db5939e5bf88104b2f34427e7316ee7b9", GitTreeState:"clean", BuildDate:"2020-07-14T14:34:36Z", GoVersion:"go1.13.12", Compiler:"gc", Platform:"linux/amd64"}
OS (e.g. from /etc/os-release): macos

/kind bug /area clusterctl

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 20 (17 by maintainers)

Most upvoted comments

This use case was brought up because we said we’d exclude pre-release versions when installing without a specific version.

Should we file an issue/feature request for this? (if one hasn’t already been created)

How do we overcome the issue we just had if the metadata is tied to a specific release?

I think you explained the intended workflow. So if the v0.7.x-beta.0 was cut, it would have a metadata file with this contract rule included v0.7.x -> v1alpha3. And if we implement the feature of ignoring pre-releases, then clusterctl init -i foo would move on to v0.6.4 release which would have it’s own metadata file BUT if the v0.6.4 release didn’t have a metadata file then it would revert to using the embedded metadata.

The idea is that the embedded metadata would just be a fallback but it shouldn’t be used as the sole source of truth.

Also, as you mentioned, this metadata.yaml file could be in the repo and the automation to cut a release includes it in the github release artifacts.

This issue is essentially trying to balance the UX for the infra provider authors/developers vs. the users of clusterctl.

wfernandes on Jul 30, 2020

It’s an extra GitHub API request, which counts against the low anonymous rate limit unless you’ve configured your token. But presumably it’s a one-time cost, as I would expect us to cache the contents for each release.

ncdc on Jul 30, 2020

@rushyrush you need to specify the version when running init. For some reason it is defaulting to the pre-release. Try this: clusterctl init --infrastructure=vsphere:v0.6.6

BrandenCobb on Jul 29, 2020