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

KEP-2885: Add Server-Side Unknown Field Validation KEP #2886

Merged
merged 16 commits into from
Sep 9, 2021

Conversation

kevindelgado
Copy link
Contributor

  • One-line PR description: Add initial data for KEP-2885

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Aug 20, 2021
@k8s-ci-robot k8s-ci-robot added kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. labels Aug 20, 2021
@kevindelgado
Copy link
Contributor Author

/assign @apelisse


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.
Copy link
Contributor

@smarterclayton smarterclayton Aug 23, 2021

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.

Copy link
Contributor Author

@kevindelgado kevindelgado Aug 24, 2021

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.

Copy link
Member

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.

Copy link
Contributor

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.

@apelisse
Copy link
Member

I've reviewed this and I'm happy with it.
/lgtm

I think we probably should get an early approval on that so that enhancement freeze is not as stressful. @deads2k @lavalamp

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 25, 2021
@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 26, 2021
@kevindelgado
Copy link
Contributor Author

kevindelgado commented Aug 31, 2021

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

@kevindelgado
Copy link
Contributor Author

cc @sttts Antoine mentioned you might be interested too.

@wojtek-t
Copy link
Member

/assign @deads2k


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”.
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@kevindelgado
Copy link
Contributor Author

gentle ping @deads2k

Copy link
Contributor Author

@kevindelgado kevindelgado left a 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

@deads2k
Copy link
Contributor

deads2k commented Sep 8, 2021

/label tide/merge-method-squash
/lgtm
/approve
/hold

holding to give time for other reviewers. Other reviewers have until 1pm eastern tomorrow.

@k8s-ci-robot k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges. lgtm "Looks good to me", indicates that a PR is ready to be merged. labels Sep 8, 2021
@k8s-ci-robot
Copy link
Contributor

[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 /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 Sep 8, 2021
Copy link
Member

@wojtek-t wojtek-t left a 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
Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

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

@deads2k
Copy link
Contributor

deads2k commented Sep 9, 2021

Some nits (can be addressed in a follow up).

@kevindelgado These should be addressed in followups for clarity.

/hold cancel

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 9, 2021
@k8s-ci-robot k8s-ci-robot merged commit cd041ee into kubernetes:master Sep 9, 2021
@k8s-ci-robot k8s-ci-robot added this to the v1.23 milestone Sep 9, 2021
ravisantoshgudimetla pushed a commit to ravisantoshgudimetla/enhancements that referenced this pull request Sep 9, 2021
* 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
rikatz pushed a commit to rikatz/enhancements that referenced this pull request Feb 1, 2022
* 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
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. kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants