-
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 types #4928
⚠️ Add ClusterClass types #4928
Conversation
// tolerate version strings without a "v" prefix: prepend it if it's not there | ||
if !strings.HasPrefix(c.Spec.Topology.Version, "v") { | ||
c.Spec.Topology.Version = "v" + c.Spec.Topology.Version | ||
} |
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.
Let's remove this assumption and only accept versions with v
prefix?
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.
This will make this version field behave differently from the other version fields, I would prefer consistency vs being strict.
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.
@CecileRobertMichon thoughts?
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 with Fabrizio on this one, consistency is better. But we can open an issue to consider requiring the "v" prefix on all version fields across the API. Although IMO it's nice to not have to worry about it as a user, functionally it's the same.
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.
There is similar toleration currently on Machine and MachineDeployment. We should have a single approach for all version fields. Either all or none!
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'll open an issue to not make it easier for users but rather acknowledge that it should always be prefixed with v
. The reason to drop the simplified approach is that we're making an assumption which isn't clear to the user until they get/describe the object. This can also break gitops.
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.
minor nits and questions.
// tolerate version strings without a "v" prefix: prepend it if it's not there | ||
if !strings.HasPrefix(c.Spec.Topology.Version, "v") { | ||
c.Spec.Topology.Version = "v" + c.Spec.Topology.Version | ||
} |
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.
There is similar toleration currently on Machine and MachineDeployment. We should have a single approach for all version fields. Either all or none!
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.
very nice, just a bunch of nits
All the comments should be addressed |
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.
very minor nits, but otherwise lgtm.
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
118809d
to
1d9c337
Compare
15d095a
to
d46babc
Compare
Nice! |
f021a62
to
38fc771
Compare
@vincepri last set of comments are addressed, PR rebased, commit squashed |
/test pull-cluster-api-test-main |
/retest |
1 similar comment
/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.
/lgtm
/assign @CecileRobertMichon
for approval
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.
Sorry for the late review, finally got the chance to go through everything
@@ -13,6 +13,9 @@ resources: | |||
- group: cluster | |||
kind: MachineDeployment | |||
version: v1alpha3 | |||
- group: cluster | |||
kind: ClusterClass |
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.
what is our strategy for introducing new CRDs in terms of API versions? We should discuss, there was also #4917 on the topic
seems like it'd make more sense to introduce new APIs at alpha once we move to beta for the rest of the project.
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 in defining policies, but I think the two usa case have a key difference.
In the case of ClusterClass we are adding a new type to the main CAPI group, so it shares the API version of the existing types (the strategy is implicit here). In the case of the operator instead we are creating a new, separated API group so we have freedom to choose a different API version.
// NOTE: This feature is alpha; it is required to enable the ClusterTopology | ||
// feature gate flag to activate managed topologies support. | ||
// +optional | ||
Topology *Topology `json:"topology,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.
General question about the PR: does it make master unreleasable? Should we be merging new types without corresponding implementation/controllers since we're not in a "breaking change" development phase anymore and might need to release v0.4.1 any time to fix bugs? Would it be a better strategy to start a new branch for ClusterClass like we did for the provider operator work? Apologies if this was already discussed and I missed it.
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.
General question about the PR: does it make master unreleasable?
No. Master should always be ready for a release.
In order to make it possible while adding ClusterClass and managed topologies on the master branch we are avoiding breaking changes and we are keeping all the new features behind a feature flag, and if the flag is false (which is the default), Cluster API just works as of today with web hooks enforcing you can't set Cluster.Topology or Create/Update ClusterClass types. Also, keeping "strict" isolation between ClusterClass and existing controllers is a driving principle of the next steps of this effort, see e.g. notes on #4933.
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, as long as webhooks are installed (which we always assume) we should be fine. While the fields show up within the CRDs, enabling the feature gate won't do much more than enabling something non functional.
One thing I'd add into the comment for now is This feature is alpha, highly experimental, and parts of it might still be not implemented
38fc771
to
d027c3c
Compare
d027c3c
to
20c3c7e
Compare
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.
/lgtm
20c3c7e
to
fb67f57
Compare
I have updated the comment of Cluster.Spec.Topology as per @vincepri comment (reporting this feature is highly experimental, and parts of it might still be not implemented) |
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.
/approve
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri 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 |
/lgtm |
What this PR does / why we need it:
This PR add new ClusterClass types/change Cluster API type as defined in the ClusterClass proposal.
Also related web hooks implementation/changes are included in this change set.
Which issue(s) this PR fixes:
Fixes #4908