-
Notifications
You must be signed in to change notification settings - Fork 114
Add validation of managed labels/annotations #134
Add validation of managed labels/annotations #134
Conversation
Hi @erikgb. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
b9c5dcf
to
4f5145d
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.
I'll only be able to look at this tomorrow.
Ryan, if you have a few minutes to check this out and like it, feel free to lgtm/approve without me! Otherwise I'll get it tomorrow.
/cc @rjbez17
4f5145d
to
31d8df5
Compare
FYI: I removed some refactoring/cleanup that can be done in a separate PR. Ready for review. |
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 this is sufficient testing. We generally don't have e2e tests (which is what I think you mean by "integration tests"?) for webhook validation except to make sure that it's set up at all. Unit tests are more than enough to test whether the logic is correct.
Otherwise, this lgtm apart from some small requests. Thanks!
1b71be0
to
3e31634
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.
Sorry four last nits! LMK if you disagree with them.
allErrs := validateManagedMeta(req.hc) | ||
if len(allErrs) > 0 { | ||
gk := schema.GroupKind{Group: api.GroupVersion.Group, Kind: "HierarchyConfiguration"} | ||
err := apierrors.NewInvalid(gk, req.hc.Name, allErrs) | ||
return webhooks.DenyFromAPIError(err) | ||
} | ||
|
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.
Can we shorten this even more? I like the lower-level function to encapsulate as much information as possible so that the top-level function is easier to read, e.g:
if denied := validateManagedMeta(req.hc); denied != nil {
return denied
}
Now the caller (handle()
) doesn't have to know anything about the type of information coming out of validateManagedMeta
other than that it's ready to be returned to its caller (Handle()
).
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 reason I left the allErrs
there, is to make it more obvious how to include more field errors in the same response. And to avoid more refactoring if/when more fields are added to HierarchyConfiguration
that require validation in this webhook.
If we were using the high-level webhook framework provided by controller-runtime, Error
/field.ErrorList
is the "contract" between your webhook implementation and controller-runtime. That is another reason for keeping it as suggested IMO.
So here I do not agree with you, and would like to keep it as is. But if you insist..... 😉
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.
Interesting. Let's leave it as-is for now, but generally I prefer to keep the current state of the code as readable as possible, and save the flexibility until we actually use them in the PRs. But especially if you'll be adding that shortly, it's fine to go in like this.
defer func() { | ||
_ = config.SetManagedMeta(nil, nil) | ||
}() |
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.
Why not defer config.SetManagedMeta(nil, nil)
? Is the anonymous function adding anything?
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.
Just my IDE complaining about unhandled error, but in this case it's "wrong". 😅 Fixed.
Part of kubernetes-retired#47. This adds validation of managed labels and annotations. Tested: Added unit tests for validations. Ran e2e-tests, but no additions/modifications to those in this PR.
3e31634
to
7db7393
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
/approve
allErrs := validateManagedMeta(req.hc) | ||
if len(allErrs) > 0 { | ||
gk := schema.GroupKind{Group: api.GroupVersion.Group, Kind: "HierarchyConfiguration"} | ||
err := apierrors.NewInvalid(gk, req.hc.Name, allErrs) | ||
return webhooks.DenyFromAPIError(err) | ||
} | ||
|
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.
Interesting. Let's leave it as-is for now, but generally I prefer to keep the current state of the code as readable as possible, and save the flexibility until we actually use them in the PRs. But especially if you'll be adding that shortly, it's fine to go in like this.
/ok-to-test |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: adrianludwin, erikgb 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 |
Closes #128. Part of #47.
This adds webhook validation of managed labels and annotations.
Tested: Added unit tests for validations. Ran e2e-tests, but no additions/modifications in this PR.
/cc @adrianludwin