-
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
🌱 Add ClusterClass variables to status on reconcile #7991
🌱 Add ClusterClass variables to status on reconcile #7991
Conversation
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.
/hold
This PR contains a couple of necessary commits from other PRs, so it should not be merged until they're also merged.
/remove-hold |
@killianmuldoon Please rebase, when you have some time
I assume this is not the case anymore? |
c232f78
to
2d21ae8
Compare
Yeah - those PRs are now merged. |
/remove-hold Underlying PRs are now merged. |
2d21ae8
to
f8ac252
Compare
@@ -86,7 +86,7 @@ status: | |||
variables: |
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.
@vincepri would really appreciate if you have the time to review the API, particularly how the variables appear in ClusterClass .status
and how they can be defined by users in Cluster .spec.topology
.
We had a discussion about it - with @sbueringer, @fabriziopandini, @ykakarap - but it would be good to get another set of eyes 🙂
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.
+1 to the current naming from my side as discussed
/retest |
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.
Just nits. But lets wait to address them after the API is finalized.
6a0737a
to
15c89dd
Compare
docs/book/src/tasks/experimental-features/runtime-sdk/implement-topology-mutation-hook.md
Outdated
Show resolved
Hide resolved
docs/book/src/tasks/experimental-features/runtime-sdk/implement-topology-mutation-hook.md
Outdated
Show resolved
Hide resolved
internal/controllers/clusterclass/clusterclass_controller_test.go
Outdated
Show resolved
Hide resolved
/retest rate limit flake |
15c89dd
to
4d093c7
Compare
/lgtm |
LGTM label has been added. Git tree hash: bd1204d15693e08725836e43f2424bbc1ad98b21
|
// DefintionsConflict specifies whether or not there are conflicting definitions for a single variable name. | ||
// +optional | ||
DefintionsConflict bool `json:"defintionsConflict,omitempty"` |
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.
// DefintionsConflict specifies whether or not there are conflicting definitions for a single variable name. | |
// +optional | |
DefintionsConflict bool `json:"defintionsConflict,omitempty"` | |
// Conflicts specifies whether or not there are conflicting definitions for a single variable name. | |
// +optional | |
Conflicts bool `json:"conflicts,omitempty"` |
Maybe?
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.
Not sure if the additional Definitions is better. Essentially it's variables[].definitionsConflict
vs variables[].conflicts
The additional hint that the definitions conflict and not the variable itself might be more intuitive
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.
+1 I also prefer definitionsConflict here (assuming we're sticking with definition
)
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 slightly in favor of .conflict, it is simpler and in this struct we only have definitions, so...
But I will be ok with both.
- name: http-proxy | ||
namespace: inline | ||
definitionFrom: inline |
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.
Are there alternative names to this variable? Don't have better ideas right now, but not sure if it's immediately clear that this is where the schema of the variable is defined
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 guess schemaFrom could be an alternative. We just used definitions in the ClusterClass.status so it's nice if that matches up. We used definitions there as it felt consistent to patches[].definitions.
But we could change both places to ClusterClass.status.variables[].schemas and Cluster.spec.topology.variables[].schemaFrom
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.
But I think I prefer definition / definitionFrom over schema / schemaFrom as we also have schema one level deeper already to describe the actual VariableSchema (which doesn't include if the variable itself is required). So it's confusing if we have it on both levels.
To summarize. Variable definition for us is:
- the name of the variable
- the VariableSchema
- if the variable itself is required
Based on that it seems fitting to go with definition rather than schema
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 think we should be consistent with whatever we go for here - but in the existing API Schema
is below Definition
as Stefan said, open to other options for the word though.
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 +1 with definition, it is a consistent with what we have in clusterClass
4d093c7
to
f5068cf
Compare
f5068cf
to
0118e20
Compare
/lgtm |
LGTM label has been added. Git tree hash: a2c2c987c02eb3163347cb126bb0badb410b907e
|
|
||
// VariableDefinitionFromInline indicates a patch or variable was defined in the `.spec` of a ClusterClass | ||
// rather than from an external patch extension. | ||
VariableDefinitionFromInline = "inline" |
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.
wondering if inline is clear enough for users looking at the cluster, but I don't have better suggestions 😓
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 not sure if there are better options, given that we define variables that are defined in the ClusterClass as "inline variables" everywhere
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.
The other option IMO is to be completely literal and point to 'ClusterClass .spec.variables'. I think this assumes too much knowledge of the ClusterClass to Cluster authors.
Cluster authors should really see and treat this as meaningless name for setting variables. For ClusterClass authors they should know what inline patches and variables.
Let's merge this, so we unblock other work. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini 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 |
Add variables from the ClusterClass
.spec
to its.status
field on each reconcile. This change is the foundation for introducing external variables which can be kept in sync in the ClusterClass status.Part of #7985