kubernetes-sigs
Add support for optional providers to clusterctl
With the IPAM Proposal (#6000) and CAPI Runtime Addons coming up, it needs to be decided how those components can be installed through clusterctl.
Currently clusterctl differentiates between different kinds of providers (CoreProvider, InfrastructureProvider, BootstrapProvider etc.). This differentiation is used to perform some basic sanity checks when installing a new cluster, ensuring that at least one of each provider category is installed.
We could either add additional categories (e.g. IPAMProvider) or create a generic one for all optional providers. There is some discussion on Slack.
/kind feature
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
thinking about this:
- clusterctl offers a set of capabilities that could apply to any component that could be part of a management Cluster, like e.g. it manages all the artifact retrieval, some manipulation like changing namespaces or doing envsubst, labeling objects so they can deleted/upgraded and it also provide a way to define compatibility matrix via metada.yaml
- clusterctl already extended the definition of providers, originally derived from "infra provider", to include also core-provider, bootstrap-provider, control-plane providers
- if we continue down this path, by extending the meaning of provider by including IPAM, then we can benefit of all the clusterctl machinery and provide a consistent UX for the users
I will raise the point in the office hours, trying to get consensus on this path forward. Notably, we should also decide if the same approach can be used for other things like Runtime Extension and Cluster Addon Providers
we talked about this during the community meeting today, imo it sounds like a good idea on balance.
one thing we discussed during the meeting was the notion of compatibility between various providers. it would be nice if a user could know that some combinations might not work, or will produce unexpected results. having deep logic to detect these combinations is probably not what we want, but if there is a use case then we might add metadata which could advertise known compatibilities, or something similar.
as @fabriziopandini mentioned in the meeting, we can always approach this as a phased effort where we follow up with the compatibility work after the initial feature work. i agree with this idea and i think it would give us time to collect user stories about what we might want, if there is no need then perhaps there is nothing to do here (speaking specifically about compatibility).
