Cluster-api: Opt-in/out of allowing cluster-api to upgrade cert-manager

[MPV]

User Story

As a operator I would like to be able to run my cluster-api management cluster in an existing cluster which happens to already run cert-manager (without CAPI changing or upgrading my cert-manager installation).

Detailed Description

As a rough draft, I'm suggesting to make the installation of cert-manager into a separate provider, which can be manually included/excluded from clusterctl init (like other providers) using flags/config.

Anything else you would like to add:

Related to issue in #3836.

Also, a big caveat to that I'm not too familiar with the cluster-api internals yet, so while I suggest a "provider" specifically, I understand it might not be the right abstraction.

I hope what I'm after is understandable (reusing the somewhat similar concept of how the providers can be optionally installed).

/kind feature

[MPV]

Question related to sharing the capi management cluster with other things:

Am I right in assuming that clusterctl delete would also remove all cert-manager CRDs after itself, and thus break existing cert-manager usage in said shared management cluster?

[fabriziopandini]

As of today, you can already install by yourself cert-manager, and clusterctl will recognize it is installed (and skip upgrade if the installed version is higher than v0.16.1).

If we want to make this option more explicit, I'm fine with that, but I don't think that assimilating cert-manager to a provider is the right approach, because this will create more problems than benefits along the line.
Cert-manager is a pre-requisite, not a provider.

[fabriziopandini]

WRT to delete, clusterctl is not going to delete cert-manager. see also https://github.com/kubernetes-sigs/cluster-api/issues/3722#issuecomment-704353088

[MPV]

My point is that if cert-manager is shared in a cluster, one might not want cluster-api to dictate/take over when upgrades/changes to it is made, but rather allow it to (at least opt-in) have it's own lifecycle managed elsewhere.

As of today, you can already install by yourself cert-manager, and clusterctl will recognize it is installed (and skip upgrade if the installed version is higher than v0.16.1).

If we want to make this option more explicit, I'm fine with that, but I don't think that assimilating cert-manager to a provider is the right approach, because this will create more problems than benefits along the line.
Cert-manager is a pre-requisite, not a provider.

I see what you mean, and maybe the title should be renamed to be less about cert-manager being a provider, and more about it being opt-in for cluster-api to not touch an existing installation of cert-manager. 😊

[MPV]

Renamed title now, hope it makes sense?

[jan-est]

+1 for this.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[wcurry]

+1 from me.