cluster-api
cluster-api copied to clipboard
kubernetes-sigs
📖 Cluster API Add-on Orchestration proposal
What this PR does / why we need it:
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 #
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
Thanks for putting this together! Is my understanding correct that as for now ClusterAddonProvider would be an abstract concept that has no programatic contracts? Is the intent for each provider e.g helmProxy to live in the capi vs being independent projects?
@enxebre Those are both good questions. As for now we don't necessarily have a programmatic contracts, but as the Helm provider implementation moves forward I'd expect to revisit this and decide which parts we'd want to make common to all ClusterAddonProviders. I think the Helm provider could live in CAPI as a reference implementation provided out of the box but I'm not sure how we'd want to proceed with other providers.
I've made some additional changes and fixed some nits in the proposal. I think this is ready for a final pass of reviews!
Thanks for putting this together! Is my understanding correct that as for now ClusterAddonProvider would be an abstract concept that has no programatic contracts? Is the intent for each provider e.g helmProxy to live in the capi vs being independent projects?
Can we clarify the API plan? Is the plan for the API to release as addons.cluster.x-k8s.io/v1alpha1 and go from there?
Is the code expected to live in exp/ initially or something else? As it stands the proposal seems completely orthogonal to core CAPI resources therefore I question if it should live in a separate repo?
@enxebre I was planning on bringing it up as a discussion topic soon, but I think the community will need to decide if this project should move into CAPI as a reference implementation similar to CAPD or live in its own provider repo. I'm happy to discuss what the community prefers in a meeting or over Slack. To answer your question though, if we were to merge this into CAPI, I was thinking would merge the API and types into exp and gradually merge the controller prototype code by splitting it up into several PRs.
Last two from my side:
- https://github.com/kubernetes-sigs/cluster-api/pull/6905#discussion_r983288112
- https://github.com/kubernetes-sigs/cluster-api/pull/6905#discussion_r983290464
@sbueringer @fabriziopandini @CecileRobertMichon It looks like the discussion is wrapping up. Should we start a lazy consensus timer to get this merged?
+1 on starting lazy consensus
Let's set the lazy consensus for 7 days from now, Wednesday, October 12, 2022?
/approve /hold
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: CecileRobertMichon, fabriziopandini
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [CecileRobertMichon,fabriziopandini]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
While a nice solution, in my opinion this proposal suffers from 2 problems:
- It doesn’t integrate with the GitOps ecosystem, and in that sense is only useful for bootstrapping a GitOps engine in the newly created cluster.
- As the reference implementation shows, the concrete implementations either cannot or would require substantial work (including CRD changes) to capture or employ the richness of combining multiple package management tools (e.g. Helm and Kustomize), which the community has spent years to develop.
The Runtime Hooks proposal avoids both issues, allowing the existing user solutions to get triggered as needed (e.g. bootstrap a CNI and a GitOps engine and let it take over), and let the Kubernetes community invest in other work areas, instead of recreating solutions the community has spent years to develop and improve.
