clusterctl: Consider re-using repositoryClientFactory

[sbueringer]

While implementing #7343 we noticed that we create multiple repositoryClientFactories in clusterctl.

newClusterctlClient:

cluster-api/cmd/clusterctl/client/client.go

Lines 188 to 195 in 44f9fd9

	if client.repositoryClientFactory == nil {
	client.repositoryClientFactory = defaultRepositoryFactory(client.configClient)
	}
	// if there is an injected ClusterFactory, use it, otherwise use a default one.
	if client.clusterClientFactory == nil {
	client.clusterClientFactory = defaultClusterFactory(client.configClient)
	}

defaultRepositoryFactory and defaultClusterFactory

cluster-api/cmd/clusterctl/client/client.go

Lines 207 to 227 in 44f9fd9

	func defaultRepositoryFactory(configClient config.Client) RepositoryClientFactory {
	return func(input RepositoryClientFactoryInput) (repository.Client, error) {
	return repository.New(
	input.Provider,
	configClient,
	repository.InjectYamlProcessor(input.Processor),
	)
	}
	}
	// defaultClusterFactory is a ClusterClientFactory func the uses the default client provided by the cluster low level library.
	func defaultClusterFactory(configClient config.Client) ClusterClientFactory {
	return func(input ClusterClientFactoryInput) (cluster.Client, error) {
	return cluster.New(
	// Kubeconfig is a type alias to cluster.Kubeconfig
	cluster.Kubeconfig(input.Kubeconfig),
	configClient,
	cluster.InjectYamlProcessor(input.Processor),
	), nil
	}
	}

First we create and return a client.RepositoryClientFactory in defaultRepositoryFactory then
defaultClusterFactory creates its own cluster.RepositoryClientFactory in cluster.New. Both are using different different parameters to call repository.New.

This issue is about considerung using the same repositoryClientFactory for both (if it's doable / makes sense)

/kind cleanup
/area clusterctl
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

[fabriziopandini]

/triage accepted
As a first step, I will make sure we are always creating repository with the same parameters given that this is probably easier, but might be that there is a solution to directly move to use only one repository client

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[fabriziopandini]

/lifecycle active

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[fabriziopandini]

/triage accepted
/priority backlog

We don't have reports of this being an issue, but it still seems a nice cleanup to have
However, if nothing happens in the future, let's consider closing this ticket

[fabriziopandini]

The Cluster API project currently lacks enough active contributors to adequately respond to all issues and PRs.

/close

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

The Cluster API project currently lacks enough active contributors to adequately respond to all issues and PRs.

/close

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.