-
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
🌱 Move API v1beta1 webhooks to a separate package #9047
🌱 Move API v1beta1 webhooks to a separate package #9047
Conversation
Skipping CI for Draft Pull Request. |
/test ? |
@JoelSpeed: The following commands are available to trigger required jobs:
The following commands are available to trigger optional jobs:
Use
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/test pull-cluster-api-test-main |
7a38e98
to
9b409d8
Compare
f09e167
to
7a79d40
Compare
7a79d40
to
507cd3f
Compare
507cd3f
to
79de0a3
Compare
79de0a3
to
b501f5f
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.
Thank you very much for working on this.
Sorry for the long delay, just a few smaller findings
return &machineDeploymentDefaulter{ | ||
// MachineDeploymentWebhook creates a new Webhook for MachineDeployments. | ||
func MachineDeploymentWebhook(scheme *runtime.Scheme) Webhook { | ||
return &machineDeployment{ |
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.
WDYT about implementing this the same way as in:
v.decoder = admission.NewDecoder(mgr.GetScheme()) |
(i.e. we would drop the constructor, take the scheme from the manager in SetupWebhookWithManager and get rid of the interface, also basically this aligns it to the other webhooks)
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 I implemented the previous version and for some reason I wanted to keep SetupWebhookWithManager on the MachineDeployment object, but now it seems better to be consistent to me
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 the only risk of that, is that you then may not have a decoder present right? And in all test we would have to set up the decoder and pass through, with this at least we have that guarantee.
I can get a commit up to compare and discuss 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.
Yup. Seems a similar risk to that the Client is not set in the Cluster & ClusterClass webhooks (similar behavior in all of our controllers)
I think I'm not against ensuring that everything is there via constructors, I would mostly prefer consistency across webhooks (& ideally controllers)
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.
Basically we currently assume that webhooks & controllers are always used ~ like this:
if err := (&controllers.MachineReconciler{
Client: mgr.GetClient(),
...
}).SetupWithManager(ctx, mgr, concurrency(machineConcurrency)); err != nil {
setupLog.Error(err, "unable to create controller", "controller", "Machine")
os.Exit(1)
}
...
if err := (&webhooks.Cluster{Client: mgr.GetClient()}).SetupWebhookWithManager(mgr); err != nil {
setupLog.Error(err, "unable to create webhook", "webhook", "Cluster")
os.Exit(1)
}
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.
Maybe one option is to aim for consistency across webhooks for this PR and (if we want) do a follow-up to figure out if we want to make it safer across the board
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 at least the current layering with internal enforces that folks have to call SetupWebhookWithManager on the exported webhook struct to get an instance of the internal webhook.
So we should be able to rely on that SetupWebhookWithManager is called for the internal webhook struct
(for unit tests we have to do it correctly though :))
@sbueringer I've updated all of your requests in individual commits to make the review easier, LMK if those are good for you and I can squash back down into a single commit |
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.
Looks good thx, last round of nits
0e63639
to
8193dec
Compare
@JoelSpeed: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Thx! /lgtm /assign @vincepri @killianmuldoon |
LGTM label has been added. Git tree hash: 8f6b2fcd3d8e3d6b70def3e31ea286a7356c7184
|
/approve We can follow up if there are further findings |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbueringer 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 |
/area api |
What this PR does / why we need it:
To work towards #9011, we need to remove the reliance on controller-runtime from the API packages.
This updates the webhooks to use the CustomDefaulter and CustomValidator pattern and moves them to match the Cluster and ClusterClass webhooks. This Is a more major lift but removes quite a bit of the code from the API package itself, making it's reliance on controller-runtime a lot smaller.
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 #