Skip to content
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

Merged

Conversation

killianmuldoon
Copy link
Contributor

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

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 24, 2023
@killianmuldoon killianmuldoon mentioned this pull request Jan 24, 2023
34 tasks
Copy link
Contributor Author

@killianmuldoon killianmuldoon left a 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.

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 26, 2023
@killianmuldoon killianmuldoon changed the title 🌱 [WIP] Add ClusterClass variables to status on reconcile 🌱 Add ClusterClass variables to status on reconcile Jan 27, 2023
@killianmuldoon
Copy link
Contributor Author

/remove-hold

@k8s-ci-robot k8s-ci-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. labels Jan 27, 2023
@sbueringer
Copy link
Member

sbueringer commented Jan 30, 2023

@killianmuldoon Please rebase, when you have some time

This PR contains a couple of necessary commits from other PRs, so it should not be merged until they're also merged.

I assume this is not the case anymore?

@killianmuldoon killianmuldoon force-pushed the pr-exvars-cc-status-var branch from c232f78 to 2d21ae8 Compare January 30, 2023 14:57
@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 30, 2023
@killianmuldoon
Copy link
Contributor Author

This PR contains a couple of necessary commits from other PRs, so it should not be merged until they're also merged.

I assume this is not the case anymore?

Yeah - those PRs are now merged.

@killianmuldoon
Copy link
Contributor Author

/remove-hold

Underlying PRs are now merged.

@killianmuldoon killianmuldoon force-pushed the pr-exvars-cc-status-var branch from 2d21ae8 to f8ac252 Compare January 30, 2023 18:07
@@ -86,7 +86,7 @@ status:
variables:
Copy link
Contributor Author

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 🙂

Copy link
Member

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

@sbueringer
Copy link
Member

/retest

Copy link
Contributor

@ykakarap ykakarap left a 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.

api/v1beta1/clusterclass_types.go Outdated Show resolved Hide resolved
api/v1beta1/clusterclass_types.go Outdated Show resolved Hide resolved
@killianmuldoon killianmuldoon force-pushed the pr-exvars-cc-status-var branch 2 times, most recently from 6a0737a to 15c89dd Compare January 31, 2023 10:34
@sbueringer
Copy link
Member

/retest

rate limit flake

@killianmuldoon killianmuldoon force-pushed the pr-exvars-cc-status-var branch from 15c89dd to 4d093c7 Compare January 31, 2023 13:02
@sbueringer
Copy link
Member

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 31, 2023
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: bd1204d15693e08725836e43f2424bbc1ad98b21

Comment on lines +574 to +576
// DefintionsConflict specifies whether or not there are conflicting definitions for a single variable name.
// +optional
DefintionsConflict bool `json:"defintionsConflict,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// 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?

Copy link
Member

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

Copy link
Contributor Author

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)

Copy link
Member

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.

api/v1beta1/clusterclass_types.go Outdated Show resolved Hide resolved
- name: http-proxy
namespace: inline
definitionFrom: inline
Copy link
Member

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

Copy link
Member

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

Copy link
Member

@sbueringer sbueringer Jan 31, 2023

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

Copy link
Contributor Author

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.

Copy link
Member

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

@killianmuldoon killianmuldoon force-pushed the pr-exvars-cc-status-var branch from 4d093c7 to f5068cf Compare January 31, 2023 16:01
@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 31, 2023
@killianmuldoon killianmuldoon force-pushed the pr-exvars-cc-status-var branch from f5068cf to 0118e20 Compare January 31, 2023 16:29
@sbueringer
Copy link
Member

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 31, 2023
@k8s-ci-robot
Copy link
Contributor

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"
Copy link
Member

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 😓

Copy link
Member

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

Copy link
Contributor Author

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.

@fabriziopandini
Copy link
Member

Let's merge this, so we unblock other work.
We can iterate on those names later on if necessary; please open an issue/add a point in your tracking issue about doing a final UX audit of this feature later in the cyle with links to the above threads
/lgtm
/approve

@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 1, 2023
@k8s-ci-robot k8s-ci-robot merged commit e9a7318 into kubernetes-sigs:main Feb 1, 2023
@k8s-ci-robot k8s-ci-robot added this to the v1.4 milestone Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants