-
Notifications
You must be signed in to change notification settings - Fork 40.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
CRDValidationRatcheting: Factor object correlation and comparison into reusable component #121118
CRDValidationRatcheting: Factor object correlation and comparison into reusable component #121118
Conversation
inlineValidator unnecessary, since we already have access to the `new` object
so it is reusable by CEL validators
going to be used from CEL validator too
for reuseability with CEL structural schema impl
/triage accepted |
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.
Thanks! I don't see a lot of tests throughout, maybe they didn't need to be updated, if so that's great!
staging/src/k8s.io/apiextensions-apiserver/pkg/apiserver/validation/ratcheting.go
Show resolved
Hide resolved
staging/src/k8s.io/apiextensions-apiserver/pkg/apiserver/validation/ratcheting.go
Outdated
Show resolved
Hide resolved
staging/src/k8s.io/apiextensions-apiserver/pkg/apiserver/validation/ratcheting.go
Outdated
Show resolved
Hide resolved
b7b93de
to
92158e0
Compare
before it required running validation first, now it builds the tree as needed
no changes except package naming
be95cb9
to
e129fb6
Compare
e129fb6
to
1103e23
Compare
/lgtm |
LGTM label has been added. Git tree hash: 243cf219e4927f96da3939517d6e4e1f64f3383b
|
/assign jpbetz |
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.
Nothing major, just some godoc suggestions and switch handling suggestions.
// Atomic lists are not correlatable by item | ||
// Ratcheting is not available on a per-index basis | ||
return nil | ||
default: |
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.
label this as case "granular"
since that is what it's for and leave a default with panic as the fall-through if somehow this function ever receives a list type we don't expect?
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.
@apelisse pointed out the default list type was atomic
, so this default
case treating it as granular may be a bug. (I don't believe we have granular lists)
This was also pointed out by @apelisse when the code originally went in last release, but we decided to punt whether we should treat list items as granular for the purposes of DeepEqual comparison in ratcheting.
On one hand it'd be nice to allow users to do a point modification on a single element with ratcheting. On the other hand, there would be no CEL escape hatch for schemas that want to opt out of that behavior, and it'd be weird to allow point modification without allowing adding/removing.
Given the inconsistency and the low perceived benefit. I think we should drop support for ratcheting uncorrelatable array items in beta. (i.e. only map-type is ratchetable. Same as CEL). WDYT @apelisse @jpbetz ?
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.
only map-type is ratchetable. Same as CEL
That's the way to go. You can't correlate atomic, and it's either atomic or map-type/set. Mapping by index doesn't really make sense 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'm okay with deferring ratcheting on listType=atomic. I see the main benefits being cases where we're working on values nested under a listType=map.
Good catch on the default=atomic BTW. We should strive to always structure switch statements to reflect that.
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.
added case for "" to be equivalent with atomic
, disallowed default case ratcheting, and updated tests
Updated with latest feedback. @apelisse PTAL |
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
LGTM label has been added. Git tree hash: 36e85dbd304de1c8900d6d9818e7a162cc7d500a
|
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alexzielenski, apelisse, jpbetz 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 |
discussion: kubernetes/kubernetes#121118 (comment) Kubernetes-commit: fb1fc8b4a72758688d1251278579b2b0ac666fc7
discussion: kubernetes/kubernetes#121118 (comment) Kubernetes-commit: fb1fc8b4a72758688d1251278579b2b0ac666fc7
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
CachedDeepEqual is needed for #121016 to use with the CEL validator. It will also be neeed for native types in declarative validation. This PR factors out the object correlation and comparison tree into a re-usable component. At validation time the instance can be shared by all validation passes.
Tried to keep all commits semantically a no-op
Which issue(s) this PR fixes:
N/A
Special notes for your reviewer:
/assign @apelisse
/sig api-machinery
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: