Validate resource definitions

[willthames]

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, patch or replace.

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:

• Should we just build a useful subset of resource definitions to include with the client
• Should we turn the resource definitions into a separate python module suitable for optionally installing alongside the client
• Should we just download the appropriate schema from the internet (i.e. github in this case) when a validation is requested and cache somewhere appropriate
• Is this change more appropriate for the kubernetes client than the openshift client? Or is it something that should be the responsibility of the openshift client caller?

[fabianvf]

@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/v2 in 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.

[openshift-bot]

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

[willthames]

I think we can close this one - validate has been in for a while!