✨Allow to utilize providers from clusterctl.yaml file in /config/clusterctl.yaml

[Danil-Grigorev]

What this PR does / why we need it:

This allows to pass a default clusterctl.yaml file to the operator to fetch provider list from.
The file should be located under /config/clusterctl.yaml.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

[Fedosin]

/retest

[Fedosin]

Default providers are hardcoded in clusterctl: https://github.com/kubernetes-sigs/cluster-api/blob/9d36ddcbf8381574a86cebeacdcdfc85bafa71e9/cmd/clusterctl/client/config/providers_client.go#L128

For a custom provider you should append its URL to the FetchConfig inside Provider CR spec. https://github.com/kubernetes-sigs/cluster-api-operator/tree/main/docs#provider-spec

Can you elaborate more on how you want to use clusterctl.yaml file?

[Danil-Grigorev]

Clusterctl.yaml has a list of repositories, which extend the default list and can provide a CAPI Operator installation a list of “non-default” repositories to use, without a need to specify fetch-config for everything which is not in the hardcoded list of defaults bound to a release version. The file can be mounted as a ConfigMap, and this supports autoreload, so this list could be constantly up-to-date, disregarding the release. Additionally it allows to bound a default for a set of provider manifests to specific version, instead of latest.

[Fedosin]

I would recommend against it. It complicates the logic of the operator and makes it harder to troubleshoot potential issues. It seems to me that the current way when you can declare custom providers only in the CR specification is the best way.

@alexander-demicev @furkatgofurov7 @damdo your opinions?

[Danil-Grigorev]

As this is an opt-in functionality and is a part of the default embedded fetch configuration. Operator default behavior does not change. FetchConfig has a higher priority than the content of the provider file, so declarative approach is preserved.

[alexander-demicev]

/retest

[Fedosin]

/retest

[alexander-demicev]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexander-demicev

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [alexander-demicev]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Fedosin]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 39862d6bcfb25e9c13d92eac00b4f727dc8f225f