Re: [kubernetes/kubernetes] Remove client side validation in kubectl (#39434)
Antoine Pelisse
Trying to start a discussion about that topic: https://docs.google.com/document/d/18nrtJ0gizVHnIhx5NIkGXvSaQ1wT2i6XVDUmmQqc7_4 (shared with kubernetes-dev)
cc @bgrant0607 @smarterclayton @kubernetes/sig-api-machinery-api-reviews
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Angus Lees
I would very much like to keep a tool that validates whether some k8s YAML is valid offline for use in git pre-merge checks, etc. It doesn't have to be perfect, but being able to detect missing/typo'd fields and incorrect object structure is sort of necessary with JSON/YAML.
I understand this bug is about kubectl (and other kubernetes/* tools) specifically, but the general gist seems to be that we don't see any value in the general goal of validating separately to actually trying to modify the server resource. Is that for real?! I expected instead to see more emphasis on exposing sufficient information through discovery, openapi, etc to fill any gaps identified, rather than tearing it all out seemingly without objection :(
Well I'm objecting! 😛
Consider this a big vote for keeping client-side validation as a goal (in some form, not necessarily what's currently in kubectl).
Antoine Pelisse
I don't think we ever wanted (or at least not me) to remove the existing layer of validation from the client, but provide the validation on the server on top of the client validation. Unfortunately, this effort kind of died with #55358.
Orthogonally, the "lint"-ing kind of validation is also a perfectly valid use-case that I'd like to see addressed.
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale
Nikhita Raghunath
/remove-lifecycle rotten
Tanmai Gopal
I'm in support for removing this feature from kubectl, so that kubectl only does json/yaml syntax validation, because we're looking at a use-case for modifying the structure of say a deployment.yaml on the client side, which will finally be corrected with a mutating webhook admission controller.
Antoine Pelisse
We'll probably move that validation to the server while working on server-side apply. @coco98, I'd be more than happy to know more about your use-case though, since I'm not convinced this is the way to go. This thread has been mostly addressed by having the validation done with the openapi. I'm not sure it should be kept open.
Brian Grant
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Nikhita Raghunath
/remove-lifecycle stale
Stefan Büringer
sbueringer left a comment (kubernetes/kubernetes#39434)https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/2885-server-side-unknown-field-validation#motivation is completed now. What does that mean for this issue?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Jordan Liggitt
liggitt left a comment (kubernetes/kubernetes#39434)The fallback in kubectl from server-side to client-side validation when it detects the server doesn't support KEP-2885 (which would only be <1.25 servers by default) should be removed at this point
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.