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 types #4928

Merged

Conversation

fabriziopandini
Copy link
Member

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

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jul 13, 2021
@k8s-ci-robot k8s-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Jul 13, 2021
api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
Comment on lines +56 to +61
// 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
}
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor

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.

Copy link
Contributor

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!

Copy link
Member

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.

api/v1alpha4/clusterclass_webhooks.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks.go Outdated Show resolved Hide resolved
Copy link
Contributor

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

api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
Comment on lines +56 to +61
// 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
}
Copy link
Contributor

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!

api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks.go Outdated Show resolved Hide resolved
Copy link
Member

@sbueringer sbueringer left a 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

api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_types.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_types.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks_test.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks_test.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks_test.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhooks_test.go Outdated Show resolved Hide resolved
@fabriziopandini
Copy link
Member Author

All the comments should be addressed
@CecileRobertMichon @srm09 @vincepri I have kept changes to the type names in a separated commit for easier review

Copy link
Contributor

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

@fabriziopandini fabriziopandini force-pushed the clusterclass-api-types branch 2 times, most recently from 118809d to 1d9c337 Compare July 15, 2021 09:40
api/v1alpha4/cluster_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_webhook_test.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_webhook_test.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_types.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_types.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhook.go Outdated Show resolved Hide resolved
api/v1alpha4/clusterclass_webhook.go Outdated Show resolved Hide resolved
feature/feature.go Show resolved Hide resolved
@sbueringer
Copy link
Member

Nice!
/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 15, 2021
@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 16, 2021
@fabriziopandini
Copy link
Member Author

@vincepri last set of comments are addressed, PR rebased, commit squashed

@fabriziopandini
Copy link
Member Author

/test pull-cluster-api-test-main

@vincepri
Copy link
Member

/retest

1 similar comment
@vincepri
Copy link
Member

/retest

Copy link
Member

@vincepri vincepri left a 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

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

@CecileRobertMichon CecileRobertMichon left a 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
Copy link
Contributor

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.

Copy link
Member Author

@fabriziopandini fabriziopandini Jul 19, 2021

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"`
Copy link
Contributor

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.

Copy link
Member Author

@fabriziopandini fabriziopandini Jul 19, 2021

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.

Copy link
Member

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

api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
api/v1alpha4/cluster_types.go Outdated Show resolved Hide resolved
@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 19, 2021
Copy link
Contributor

@CecileRobertMichon CecileRobertMichon left a comment

Choose a reason for hiding this comment

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

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 19, 2021
@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 19, 2021
@fabriziopandini
Copy link
Member Author

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)

Copy link
Member

@vincepri vincepri left a comment

Choose a reason for hiding this comment

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

/approve
/lgtm

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

[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 /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 Jul 19, 2021
@sbueringer
Copy link
Member

/lgtm

@k8s-ci-robot k8s-ci-robot merged commit d9a16c9 into kubernetes-sigs:master Jul 19, 2021
@k8s-ci-robot k8s-ci-robot added this to the v0.4 milestone Jul 19, 2021
@fabriziopandini fabriziopandini deleted the clusterclass-api-types branch July 19, 2021 18:24
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/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add ClusterClass proposal API types
8 participants