Repository navigation
Validate resource definitions #181
Description
Activity
@willthames We've had some discussions about this. If we were going to do client-side validation, we would probably want to pull and cache the OpenAPI spec from the running server (giving us validation for all resources that exist, even if only for that cluster). The spec can be pulled as JSON or protobuf, with protobuf having a significant speed advantage. The spec is located at
/openapi/v2in kubernetes 1.10+.If we were to integrate it into the dynamic client, we would probably subclass the dynamic client and rewrite the discovery to pull/parse/cache the spec rather than the /apis api, and add the spec/validation methods to the Resource object. This would definitely be a change better suited to the Kubernetes repo, which is hopefully where the Dynamic client is going to end up anyway (kubernetes-client/python-base#56).
Just a note, a big part of the reason we migrated away from client-side spec-based validation for the dynamic client was that the spec itself was imprecise/incorrect in several areas (for example, many fields were marked as required, but the server accepts nil values, so the validation would reject nil values that the server would accept). Many of the bugs filed against the k8s_raw/openshift_raw modules in Ansible 2.5 were a result of improper specification.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting
/remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting/lifecycle frozen.If this issue is safe to close now please do so with
/close./lifecycle stale
I think we can close this one - validate has been in for a while!
This is a proposal of an idea that I'd like to implement but want some advice beforehand.
We could use @garethr's kubernetes json schema definitions to validate kubernetes resource definitions prior to calling
create,patchorreplace.The license is Apache 2.0 which is the same as this repository, so there are no licensing issues associated with just using the definitions locally. However, it could cause the size of the library to increase.
So I guess my questions are: