-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
📖 Cluster API Add-on Orchestration proposal #6905
Conversation
Skipping CI for Draft Pull Request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this generally makes sense and reads well to me, i just have a question about the API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, just a few nit picky suggestions and questions 🙏🏻
|
||
However, considering the fact that the link between Cluster lifecycle and Cluster add-on lifecycle is simpler than e.g the link between a Cluster and its infrastructure provider, in this case it is possible to adopt a simplified interaction model between Cluster API and HelmChartProxy (vs an integration model based on CRD with a set of well known field defined in the CAPI contract). | ||
|
||
In the first iteration, we will implement this as a single, concrete HelmChartProxy CRD, with a controller watching Cluster API resources, mainly the Cluster and eventually the ControlPlane object. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, it would help to clarify by making a clear separate section for Helm Implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this captures the overall problem statement and solution design well- great work!
/lgtm
Great work so far. Thx for pushing this forward! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
(I am biased, but) lgtm |
1417e4c
to
4e97a5a
Compare
Squashed and pushed again! |
4e97a5a
to
577b8c8
Compare
577b8c8
to
929e911
Compare
Thank you! /lgtm |
/lgtm |
@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 |
/lgtm |
Sounds good to me! Thanks to everyone who helped review this doc! |
Lazy consensus expired, |
[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
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold cancel |
While a nice solution, in my opinion this proposal suffers from 2 problems:
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. |
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 #