Open g-gaston opened 11 months ago
This issue is currently awaiting triage.
If CAPI Operator contributors determines this is a relevant issue, they will accept it by applying the triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
At a minimum, when you go to deploy a fresh install of CAPI right now specifying you desire to have cert-manager installed it should install the proper version matched to CAPI. It does not today. It seems this script is used with values from CI perhaps? to deploy cert-manager 1.13.2 and the current deployment of CAPI is 1.14.2 version of cert-manager.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
User Story
As an operator I would like the CAPI operator to manage updates to cert-manager for me so it's kept in sync with my providers' dependencies.
Detailed Description
cert-manager
support was recently introduced in https://github.com/kubernetes-sigs/cluster-api-operator/pull/144. This facilitates a lot the first CAPI bootstrap, making it almost a one command task.I understand that initially it was made a non-goal to manage cert-manager and that was left to the user. However, I do agree that the path initiated by #144 is the right one, given that most users want a simple and streamlined experience, leaving the dependency management to the CAPI tooling. I believe this is specially true for users coming from
clusterctl
, where cert-manager is automatically managed (installation and updates). And in this new path, I think there are few places where the experience can be improved:crds
folder. This works great for the initial installation, but any future cert-manager update that includes changes to the CRD will fail, since helm won't update them.Ideally, we would handle these two scenarios automatically by updating cert-manager to the required version by the core provider. This eliminates the need for the user to keep track of cert-manager versions, run manual CRD upgrades, check the version required upstream and ultimately streamlines the CAPI management experience in the same way
clusterctl
does. However, this presents some challenges:helm install
. Then let the operator update that version based on the selected CoreProvider.Alternatively, if we decided that moving this responsibility to the operator code is too much and/or we wanted to address this issues sparely, we could manage cert-manage CRDs updates using helm hooks and a kubernetes
Job
, similar to what I propose in https://github.com/kubernetes-sigs/cluster-api-operator/issues/188.Anything else you would like to add:
This is not a full fledged proposal and there are definitely some gaps in the design, but looking for feedback before investing more time on this.
/kind feature