-
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
📖 Runtime SDK proposal #6181
📖 Runtime SDK proposal #6181
Conversation
Thanks @fabriziopandini looks great to me overall. I'm only missing some concrete good real world examples that users are having to workaround or lacking support today that would be solved by this powerful system, so it's clear what it's driving the effort. It'd be good if folks can chime in so we can flesh out the user stories with those concrete examples that are not solved today. |
from community meeting on 9 march 2022, comments have been addresses, please have another review to see if we can merge |
lgtm pending squash from my side |
just a few questions, lgtm overall, no objections to proceed. |
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
as per March 23th office hours discussion we are setting a lazy consensus deadline for the 1st of April |
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
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'm happy to see the project is moving in this direction! I think there is one more thing that can be mentioned in the proposal. If hooks API structures are meant to be reused by other projects, we should keep the package that contains them separated from controller-runtime or any other dependencies if possible. Even with lazy load, go will fetch dependencies for the entire package. In order to avoid this coupling, webhooks or any helpers can be placed in separate packages.
I assume you are referring to things like the Request/Response types we will use for the Runtime Hooks? The current plan is that those can be used to implement Runtime Extensions. The current idea is to put them into a similar package structure like our regular API types ( P.S. Other things surfaced in this proposal like catalog / registry will definitely be in separate non-versioned packages. Same applies to other utils. /lgtm |
b48a6ed
to
927560a
Compare
fixed last round of nits and squashed commits |
/lgtm |
//lgtm |
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 looks really thorough to me, thanks for all the hard work
/lgtm
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.
/approve
/lgtm
/hold
for other reviewers
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri 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 |
What this PR does / why we need it:
This proposal introduces the Cluster API Runtime SDK, a set of rules, recommendations, and fundamental capabilities required to implement a new extensibility mechanism that will allow systems, products, and services built on top of Cluster API to interact with the Workload Cluster’s lifecycle.
Which issue(s) this PR fixes:
Fixes #5175