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

[ykakarap]

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

[ykakarap]

Prospect Solution: We should be able to skip performing the List operation during InitImages if the cluster is not already initialized.

[ykakarap]

/help

[k8s-ci-robot]

@ykakarap: This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[valaparthvi]

Interested :hand: I'd like to take this up if that's alright.

[ykakarap]

Perfect, go ahead. :)

/assign @valaparthvi

[valaparthvi]

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

[fabriziopandini]

/triage accepted

[ykakarap]

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.

[valaparthvi]

Exporting the GITHUB_TOKEN worked. Thanks!

[valaparthvi]

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 :raised_hands:

/unassign

@dharmit this might interest you.

[aniruddha2000]

/assign

[aniruddha2000]

@ykakarap When I created a kind cluster and run the clusterctl init --infrastructure gcp --list-images & clusterctl init --list-images it gave the list of images.

Then how I can reproduce the above error message with the clusterctl init --list-images cmd? Trying the above cmd without the kind cluster gave

Error: invalid kubeconfig file; clusterctl requires a valid kubeconfig file to connect to the management cluster: no configuration has been provided, try setting KUBERNETES_MASTER environment variable

[sbueringer]

I can reproduce with:

$ kind create cluster
$ clusterctl init --infrastructure gcp  --list-images
> Error: action failed after 9 attempts: failed get providers: no matches for kind "Provider" in version "clusterctl.cluster.x-k8s.io/v1alpha3"

[aniruddha2000]

It is strange, isn't it? 🤔

[sbueringer]

Yup.

I'm using kind v0.14.0 and clusterctl v1.2.0.

Are you sure clusterctl is accessing the kind cluster and not another one?

[aniruddha2000]

@sbueringer thanks it was clusterctl v1.1.0 for me now I upgraded and I can reproduce the same

[aniruddha2000]

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

[ykakarap]

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