cluster-api: `clusterctl init --list-images` should not need an initialized cluster

Detailed Description

clusterctl init --list-images currently requires that there exists a cluster that is already initialized. When running with a cluster that is not initialized the command throws the following error:

Error: action failed after 9 attempts: failed get providers: no matches for kind "Provider" in version "clusterctl.cluster.x-k8s.io/v1alpha3"

This seems to be a circular dependency: Having to init before one can list the images that are needed to init.

It would be nice if we could list the images without having to have a cluster that is already initialized.

Anything else you would like to add:

We try to list the providers already installed when here: https://github.com/kubernetes-sigs/cluster-api/blob/2e73a260622410cc18e6242a0f272ee3e63e252f/cmd/clusterctl/client/init.go#L193-L196

and this causes the error. Since during InitImages we dont ensure that the providers CRD is installed the list operation fails if the providers CRD is missing.

During InitImages we don’t install the CRD (as opposed to Init) and we should continue not doing it. InitImages is effectively a dry-run operation and should not change anything on the cluster.

/kind feature /area clusterctl

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 18 (18 by maintainers)

Most upvoted comments

/assign

aniruddha2000 on Aug 18, 2022

I am un-assigning this issue from my plate, I won’t be able to work on it anytime soon. Sorry for holding it for long 🙌

/unassign

@dharmit this might interest you.

valaparthvi on Aug 16, 2022

The command uses a github token if set (using env variable GITHUB_TOKEN) to avoid rate limiting. The command can be used without providing any credentials (no github token) but there is a chance that it will hit the rate limit.

But from the log message you shared it doesn’t look like a rate limiting issue. Do you have GITHUB_TOKEN set in your environment? If so, can you check if that token as the required permissions. I believe the token just needs access to the repo scope.

ykakarap on Aug 9, 2022

Perfect, go ahead. 😃

/assign @valaparthvi

ykakarap on Jul 27, 2022

@ykakarap suppose if we specify the clusterctl init --list-images it should only fetch the container images for the core provider & bootstrap provider, right? And if I mention in the --infrastructure then it should fetch the container images for that infrastructure.

It should list all the images clusterctl will try to pull if --list-images is not specified. Consider a cluster with no providers installed. If we run clusterctl init --list-images it should list the core (default), bootstrap (default) and the control plane (default) images. If we run clusterctl init -i docker --list-images it should list core (default), bootstrap (default), control plane (default) and the infrastructure provider images.

ykakarap on Aug 24, 2022

@ykakarap I am still unclear about working with this command. I understand that running clusterctl init --list-images --infrastructure <infra-provider> will pre-pull necessary images for me, but I am facing some 401 Bad Credential error when running the command.

clusterctl init --infrastructure azure --list-images
Error: failed to get provider components for the "azure" provider: failed to get repository client for the InfrastructureProvider with name azure: error creating the GitHub repository client: failed to get GitHub latest version: failed to get repository versions: failed to get repository versions: failed to get the list of releases: GET https://api.github.com/repos/kubernetes-sigs/cluster-api-provider-azure/releases: 401 Bad credentials []

curl-ing the URL(https://api.github.com/repos/kubernetes-sigs/cluster-api/releases) works fine though.

I hope there is no prerequisite to running this command, is there? I don’t need to setup anything before hand, right?

valaparthvi on Aug 5, 2022