RFE: Runtime Extensions

[vincepri]

From a while back there has been a need for Cluster API providers to be able to define their own extensions that can work across a number of different use cases. This issue is meant to be an ongoing discussion / brainstorm on what runtime extensions goals/non-goals are, and how we can make it happen with our roadmap to beta.

Requirements

• We should reuse, wherever possible, the machinery in api-server and controller tools to generate well-defined RPC services.
• The system should be defined after the admission and mutation webhook registration mechanics present in api-server for custom resource definitions.

Goals

• To provide clear interfaces for external providers to implement their functionality.
• To support runtime registration of new extensions with clear defined boundaries and responsibilities.
• To allow to extend the validation of Cluster API resources.
• To validate provider-specific content as early as possible.
• To offer kubebuilder-like functionality to scaffold a new runtime extension in Go.

Non-Goals

• To replace the current provider model for infrastructure resources

/kind design
/kind proposal

[fabriziopandini]

+1000
my two cent

Goals:

• provide generic extension mechanism for CAPI that can be used when
  • The interaction between CAPI and the extension components requires synchronous/blocking RPC calls.
  • Given RPC call will be synchronous/blocking, and also probably adding latency, the request could be processed in a very short time.

Non Goals

• To replace the current extension mechanism used for complex, long running interactions with providers (based on CRD resources with well-know informations defined by the Cluster API contract)

[imikushin]

Can we have more context on what Runtime Extensions are, why they need to exist, and some examples of how exactly they would be used? Without such context, it's impossible (at least, for me) to understand the proposal or any reasoning about it. Thank you!

[vincepri]

@imikushin That's something we all need to figure out over time and write a proposal about it.

[vincepri]

/milestone Next
/kind proposal

[vincepri]

/milestone v1.0

[fabriziopandini]

Trying to move forward with the discussion, I have created https://docs.google.com/document/d/1WTGtu32rGlme16f3133MH9dLgiJxHtABp0pWZmamInc/edit?usp=sharing with:

• some notes about a first, concrete use case for Runtime Extension, external patches for ClusterClasses
• a first brain dump of things to be defined before writing the proposal on Runtime Extensions in Cluster API

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[fabriziopandini]

/lifecycle frozen
/assign
I will get to the community with a proposal soon

[killianmuldoon]

/area runtime-sdk