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 patch engine #5534

Merged

Conversation

sbueringer
Copy link
Member

@sbueringer sbueringer commented Oct 29, 2021

What this PR does / why we need it:
This PR implements the patch engine and variable calculation described in "Applying Patches" in: #5460 (Note: there are also code walkthroughs linked in the issue, the second one ~ still matches the code from this PR).

Goal of this PR is to add the patch engine and variable calculation.

The implementation for the inline JSON patches will be added after this PR has been merged via #5583.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

@k8s-ci-robot k8s-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 29, 2021
@k8s-ci-robot k8s-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Oct 29, 2021
@sbueringer sbueringer force-pushed the pr-clusterclass-patches-engine branch from b7ee1a5 to bab2a17 Compare October 29, 2021 14:05
@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Oct 29, 2021
@sbueringer sbueringer force-pushed the pr-clusterclass-patches-engine branch from bab2a17 to da56357 Compare October 29, 2021 14:06
@sbueringer sbueringer changed the title [WIP] ✨ Add ClusterClass patches engine [WIP] ✨ Add ClusterClass patch engine Oct 29, 2021
@sbueringer sbueringer force-pushed the pr-clusterclass-patches-engine branch from da56357 to 06c4bc0 Compare October 29, 2021 14:11
@sbueringer
Copy link
Member Author

sbueringer commented Oct 29, 2021

cc @vincepri @fabriziopandini @ykakarap @killianmuldoon @randomvariable @enxebre @schrej @vuil
(not sure who else might be interested at that stage, sorry for the ping if you're not :))

@ykakarap
Copy link
Contributor

ykakarap commented Nov 2, 2021

This is great @sbueringer!! 🚀

First pass at a high level review.
The overall implementation seems good. 👍

Some high level suggestions:

  • It would be nice if we can make a core a little more readable. Some of the variable and type names do not reflect their purpose/intent. Some examples:
    • GenerateRequest - >Request? (similarly with GenerateResponse)
    • requestToDesiredState -> updateDesiredState
    • The variable patches/patch is used in several places with different meaning. In some places it is the GenerateResponse, in some places it is the Patch from the cluster class, etc. Can we rename some of the places to make the variable naming more consistent?
  • Breaking down engine.go into several files. Grouping some of the patch functions (like patchObject, patchTemplate, patchTemplateSpec), the helper functions (like copySpec, bytesToUnstructured), etc into their own files would help with code maintenance.

Leaving this at a high level review for now as this PR is still a WIP (there are also a few TODOs in the code).

Will do a full review once PR is ready. 🙂

@sbueringer
Copy link
Member Author

  • It would be nice if we can make a core a little more readable. Some of the variable and type names do not reflect their purpose/intent. Some examples:

    • GenerateRequest - >Request? (similarly with GenerateResponse)
    • requestToDesiredState -> updateDesiredState
    • The variable patches/patch is used in several places with different meaning. In some places it is the GenerateResponse, in some places it is the Patch from the cluster class, etc. Can we rename some of the places to make the variable naming more consistent?
  • Breaking down engine.go into several files. Grouping some of the patch functions (like patchObject, patchTemplate, patchTemplateSpec), the helper functions (like copySpec, bytesToUnstructured), etc into their own files would help with code maintenance.

Thx, so far! :)

Some answers:

  • GenerateRequest and GenerateResponse were named like this as it's a common pattern in Kubernetes and gRPC to include the operation in the Request/Response name, e.g. AdmissionRequest, AdmissionResponse, TokenRequest, CertificateSigningRequest. I think it's about namespacing in general. Note: right now those structs are only part of an internal interface
  • requestToDesiredState -> updateDesiredState > Done
  • I'll rename Request/Response variables to req/resp where necessary
  • I'll move some helpers to patch.go. wouldn't split it up further as it doesn't necessarily make it more maintainable if the code is distributed over multiple files. (especially as the only consumer right now is the engine)

@randomvariable
Copy link
Member

I probably won't be able to get round to a full review before Thursday due to other stuff going on, will queue up.

@sbueringer sbueringer force-pushed the pr-clusterclass-patches-engine branch from 06c4bc0 to 009c944 Compare November 2, 2021 16:16
@sbueringer sbueringer changed the title [WIP] ✨ Add ClusterClass patch engine ✨ Add ClusterClass patch engine Nov 2, 2021
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 2, 2021
@sbueringer sbueringer force-pushed the pr-clusterclass-patches-engine branch 2 times, most recently from 23fe99f to b247ec9 Compare November 2, 2021 16:22
. "sigs.k8s.io/cluster-api/internal/matchers"
)

func TestApply(t *testing.T) {
Copy link
Member Author

Choose a reason for hiding this comment

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

I've currently only added one top-level unit test for engine.go. It seems way simpler to just have a few more cases on that level compared to more or less duplicating the whole test setup for request, applyPatchesToRequest and updateDesiredState. Please let's discuss if there are other opinions on that :)

"sigs.k8s.io/cluster-api/controllers/topology/internal/contract"
)

func TestCopySpec(t *testing.T) {
Copy link
Member Author

@sbueringer sbueringer Nov 2, 2021

Choose a reason for hiding this comment

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

Similar to engine.go, I've only added one table test for copySpec. If preferred I can duplicate the test cases for the 3 patch funcs.

I thought testing copySpec covers the most cases and the 3 other funcs are transitively tested a lot by the tests in engine_test.go

@sbueringer
Copy link
Member Author

PR should be ready for review now. (open TODOs are supposed to be solved in other PRs)

(cc @ykakarap)

@sbueringer
Copy link
Member Author

Rebase on top of main, delta:

  • Aligned to changes in the MachineDeploymentClass builder
  • Fixed the TODO about requiring IgnoreAutogeneratedMetadata because the EqualObject helper is fixed now
  • Changed enum in the api package to use iota

Copy link
Member

@fabriziopandini fabriziopandini left a comment

Choose a reason for hiding this comment

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

@sbueringer great stuff!
Mostly nits; the only thing that requires some deep dive is the usage of mergepatch.
I still need to take a better look at test for the engine

@sbueringer sbueringer force-pushed the pr-clusterclass-patches-engine branch 4 times, most recently from 0dca2b5 to 17d5386 Compare November 9, 2021 09:35
@fabriziopandini
Copy link
Member

lgtm pending squash. great stuff!

Signed-off-by: Stefan Büringer buringerst@vmware.com

Co-authored-by: fabriziopandini <fpandini@vmware.com>
@sbueringer sbueringer force-pushed the pr-clusterclass-patches-engine branch from 3768cca to 1c52899 Compare November 9, 2021 17:48
@sbueringer
Copy link
Member Author

lgtm pending squash. great stuff!

Done :)

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

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

/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 Nov 9, 2021
@k8s-ci-robot k8s-ci-robot merged commit 7233fd7 into kubernetes-sigs:main Nov 9, 2021
@k8s-ci-robot k8s-ci-robot added this to the v1.1 milestone Nov 9, 2021
@sbueringer sbueringer deleted the pr-clusterclass-patches-engine branch November 9, 2021 18:30
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.

None yet

6 participants