Provide explicit definition of variables scope in ClusterClass

[fabriziopandini]

User Story

As a user, I would like to understand what variables are meant to be used as overrides at CP/MD levels

Detailed Description

As of today, ClusterClass allows to define variables and all those variables can be used in a Cluster's topology.variables as well as for providing override at CP and MD level.

However, in practice, it really makes sense to use variables as override only a subset of variables, the ones that are used by patches impacting CP/MD of a given class.

This is currently hard to detect, especially for users which are not the ClusterClass authors, so it will be great if we can extend the current API by providing explicit information about the scope where a variable can be used.

Anything else you would like to add:

Might be it is possible to Inferr variables scope from patches, but it doesn't seem the right way to go because it will be complex and brittle.

/kind feature

[fabriziopandini]

/area topology

[fabriziopandini]

/kind api-change

[fabriziopandini]

/triage accepted

The biggest challenge here is to make sure that a variable that is meant to be used in scope is not used somewhere else, and this is complex given that variables can be used in go templates or in external patches.

[sbueringer]

 and this is complex given that variables can be used in go templates or in external patches.

With our current implementation of external patches it's impossible to decide if a variable is used in an external patch.

We could do the following:

• introduce scope
• validate inline patches against scope
• send variables based on scope to external patching (i.e. send variables which are not cluster-scoped only as template-specific variables according to their scope)

[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
/help

still something worth to discuss and address

[k8s-ci-robot]

@fabriziopandini:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/lifecycle frozen
/help

still something worth to discuss and address

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.