Topology Mutation Hook: Variable discovery

[sbueringer]

User Story

As a cluster operator I would like to not be responsible for adding variable definitions used by a Topology Mutation Hook extension manually to a ClusterClass.

(mentioned as future work here)

Detailed Description

Some background information:

• Topology Mutation Hook CAEP
• Today it is necessary to manually ensure that the variables used by a Topology Mutation Hook extension exist in the ClusterClass in which the extension is used
• This means that extension authors should document which variables are used (and their type in OpenAPI Schema v3) and ClusterClass authors have to keep the variables in the ClusterClass in sync with the extension.

It would be nice if the variable definitions would be just automatically discovered from a Topology Mutation Hook extension and "added" to a ClusterClass (details TBD).

Anything else you would like to add:

Things to keep in mind:

• The same variables with different types could be defined in multiple extensions and in the ClusterClass directly
• We have to figure out when the variables should be discovered (every reconcile is probably a bit too often)
• variables discovered from extensions should be then treated like every other variable in the ClusterClass (e.g. they should be used for validating/defaulting variables on a Cluster)
• do we discover variables per ClusterClass, per Cluster or per Extension(Config) (I lean towards per ClusterClass)
• we could consider only sending the discovered variables + builtin variables in a GeneratePatches call (and not all variables) to enforce that every extension has to "declare" the variables it uses

/kind feature

[fabriziopandini]

This is a super nice improvement, but also tricky to achieve.
I'm happy too pair in discussing a possible way forward

[fabriziopandini]

/triage accepted

[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 have started collecting some ideas on this topic, I will start moving this to a doc soon

[fabriziopandini]

/unassign
/assign @killianmuldoon
@killianmuldoon please consider if we have to keep this issue or close it now that we are tracking this work also in other umbrella issues

[killianmuldoon]

/close

The current state of this issue is covered in the proposal amendment, and the implementation issue #7985

[k8s-ci-robot]

@killianmuldoon: Closing this issue.

In response to this:

/close

The current state of this issue is covered in the proposal amendment, and the implementation issue #7985

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.