📖 Runtime SDK proposal

[fabriziopandini]

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

[enxebre]

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.

[elmiko]

from community meeting on 9 march 2022,

comments have been addresses, please have another review to see if we can merge

[sbueringer]

lgtm pending squash from my side

[enxebre]

just a few questions, lgtm overall, no objections to proceed.

[killianmuldoon]

/lgtm

[fabriziopandini]

as per March 23th office hours discussion we are setting a lazy consensus deadline for the 1st of April

[vincepri]

LGTM

[alexander-demicev]

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.

[sbueringer]

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 (api/{v1alpha1,v1alpha2}). As far as I'm aware we don't need a dependency to controller-runtime in those API packages (in contrast to the regular API types we don't have to implement CR interfaces for conversion / admission webhooks).

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

[fabriziopandini]

fixed last round of nits and squashed commits

[sbueringer]

/lgtm

[killianmuldoon]

//lgtm

[elmiko]

this looks really thorough to me, thanks for all the hard work
/lgtm

[vincepri]

/approve
/lgtm
/hold

for other reviewers

[k8s-ci-robot]

[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:

• OWNERS [vincepri]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[fabriziopandini]

/hold cancel
given that lazy consensus deadline is expired