-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
KEP-2885: Add Server-Side Unknown Field Validation KEP #2886
KEP-2885: Add Server-Side Unknown Field Validation KEP #2886
Conversation
kevindelgado
commented
Aug 20, 2021
- One-line PR description: Add initial data for KEP-2885
- Issue link: Server Side Unknown Field Validation #2885
/assign @apelisse |
c6552be
to
68e3d74
Compare
68e3d74
to
d5f8058
Compare
|
||
Another argument against this method is that for patch, strictness is handled | ||
when decoding the *result* of the patch, so it wouldn’t make sense to use | ||
Content-Type which is providing information about the inbound request body. |
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.
Although like serialization, different patch types may have different rules about strictness. Can a strategic merge patch even be strict?
I'm slightly in favor of query parameters, mostly because we can version them by the API version. Content type has to be versioned with the type (i.e. at some point if we break compat with proto2 we will have to have application/vnd.kubernetes.protobuf.2, but i'd hate to do that if we had to change the name of the mime type).
Also, mime type is slightly less discoverable in openapi, whereas parameters are more discoverable.
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.
Currently, no, a strategic merge patch cannot be strict. In theory though, this should be doable. The way I understand SMP to work is that in the mergeMap
function it goes field-by-field through the existing object and checks to see if data should be merged in from the corresponding field on the patch. If there are any extra/unknown fields in the patch, they will never be encountered and will just be ignored.
The current plan is to modify mergeMap
to track the fields of the patch as they are merged into the existing object. After all fields that can be merged from the patch are, we will know that any fields on the patch that were not merged are unknown fields and can error. Does this sound reasonable to you?
I’ve added the above along with the additional advantages of the query parameter approach to the doc.
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.
Also, mime type is slightly less discoverable in openapi, whereas parameters are more discoverable.
There is the consumes
field in paths
of the OpenAPI, we could expose the modifiers there.
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.
Yeah, but it's not called out per type (i.e. you can't describe the parameters of a mime type, just a combo of mime types, so you can document application/json;v1=blah;strict=true,as=Type
but not just "the as
parameter to a mime type" since they didn't expect composition). Parameters + openapi are more discoverable, and while I think this feels a bit closer to mime type, discoverability and documentation win for me.
76d5028
to
efcbc65
Compare
Did a pass to make sure all is ready for the upcoming enhancements freeze. I think we're good here now. Only recent change is that I discussed feature flags with @apelisse and we agree that a feature flag probably isn't necessary here. The query param should be sufficient to enable/disable this feature and since we default to disabled, a feature flag does not add much value. Happy to add it back if others disagree though. Can I get a review/PRR review @deads2k @smarterclayton |
cc @sttts Antoine mentioned you might be interested too. |
/assign @deads2k |
keps/sig-api-machinery/2885-server-side-unknown-field-validation/README.md
Show resolved
Hide resolved
|
||
Alternatively, if we don’t like the idea of using Content-Type header to | ||
determine whether the apiserver should accept or fail on unknown fields, we | ||
could pass a query param such as “?validate=true”. |
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'd probably argue for fieldValidation=Strict
instead of a bool. The default would be fieldValidation=IgnoreUnknownFields
.
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.
That makes sense, I've updated it in the KEP to reflect this for now, but agree that we can finalize it during API review.
gentle ping @deads2k |
keps/sig-api-machinery/2885-server-side-unknown-field-validation/README.md
Outdated
Show resolved
Hide resolved
keps/sig-api-machinery/2885-server-side-unknown-field-validation/README.md
Show resolved
Hide resolved
keps/sig-api-machinery/2885-server-side-unknown-field-validation/README.md
Show resolved
Hide resolved
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.
All feedback addressed. PTAL @deads2k
keps/sig-api-machinery/2885-server-side-unknown-field-validation/README.md
Outdated
Show resolved
Hide resolved
keps/sig-api-machinery/2885-server-side-unknown-field-validation/README.md
Show resolved
Hide resolved
keps/sig-api-machinery/2885-server-side-unknown-field-validation/README.md
Show resolved
Hide resolved
/label tide/merge-method-squash holding to give time for other reviewers. Other reviewers have until 1pm eastern tomorrow. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, kevindelgado 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 |
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.
Some nits (can be addressed in a follow up).
LGTM from SIG scalability perspective (although I agree with Clayton that eventually we should look into optimizing it).
###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)? | ||
|
||
Yes. From the cluster operator's side, they can restart the kube-apiserver without | ||
the UnknownFieldValidation flag set and this will disable the feature |
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.
nit: s/flag/feature gate/
- Metric name: Memory Consumption | ||
- Components exposing the metric: kube-apiserver | ||
- [x] Metrics | ||
- Metric name: Request Latency |
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.
Let's provide the exact metric name:
apiserver_request_duration_seconds
@kevindelgado These should be addressed in followups for clarity. /hold cancel |
* First draft - server-side unknown field validation * Respond to smarterclayton feedback on mergeMap and param advantages * add JSON Patch POC * Update TOC to fix CI * Update PRR * Remove feature flag, add prod-readiness, set to implementable * Add feature gate * Add note about client-go support * PRR feedback * Update TOC * rename query param * Update test plan * Address feedback around warning, update client-go option name * Warn note * spelling * Add support for warn option
* First draft - server-side unknown field validation * Respond to smarterclayton feedback on mergeMap and param advantages * add JSON Patch POC * Update TOC to fix CI * Update PRR * Remove feature flag, add prod-readiness, set to implementable * Add feature gate * Add note about client-go support * PRR feedback * Update TOC * rename query param * Update test plan * Address feedback around warning, update client-go option name * Warn note * spelling * Add support for warn option