Open Blackclaws opened 1 year ago
This is a valid ask but we've been working to make the clients as dumb as possible and offload as much as possible to the server.
I would hope one of the existing linters out there could catch something like this.
/assign @seans3
To take a look at what open API can do.
@eddiezane I get the idea behind that. And its also kind of valid to say you want to keep the client dumb. The question is whether at least adding validation for this type of builtin stable resources would be advantageous. I've not found a linter so far that doesn't accept it even if it will be rejected by the server. I get that admission hooks and custom resources are totally out of scope here as well.
From my knowledge of open api and json schemas in general there isn't an easy way to validate these sort of constraints, if any at all. That's why all validators accept it as well, the schema is correct even if the constraints don't work.
/triage accepted /priority backlog
We may not end up doing anything here but it's where we're trying to head with OpenAPI.
I just thought of a case where it wouldn't even be possible to validate this client side. If you have mutating admission hooks those could actually bring the object into a valid state if I understand correctly how they work.
There could only be a client side: "validate for default kubernetes" which isn't saying much...
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
/triage accepted
(org members only)/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
What would you like to be added:
There are certain resource types such as deployment that make assumptions about how their fields interact with each other. For example deployment expects that matchLabels matches the labels in the pod template.
Why is this needed:
Currently the only way to validate even inbuilt kubernetes resources is to dry-run them against a server. It would be nice to be able to validate such invalid manifests before having to run them against an actual kubernetes server.