According to this proposal:
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/customresources-validation.md
We accept JSON Schema for validation. Kubectl and other tools we have, uses OpenAPI to validate objects (as well as other custom validations on the server). While The proposal claims that OpenAPI and JSON Schema are compatible, but they are not. OpenAPI's Schema is a subset of JSON Schema (e.g. it does not support multiple values for type field). We would be in much better shape if we ask for the OpenAPI spec of the custom resource. In that way, we can just aggregate the Spec with current OpenAPI spec and kubectl and other tools can use that to validate the resource. If we accept a JSON Schema, it would not be possible to convert it to OpenAPI if user provides any incompatible values for that Schema.
@nikhita, @sttts @lavalamp
According to this proposal:
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/customresources-validation.md
We accept JSON Schema for validation. Kubectl and other tools we have, uses OpenAPI to validate objects (as well as other custom validations on the server). While The proposal claims that OpenAPI and JSON Schema are compatible, but they are not. OpenAPI's Schema is a subset of JSON Schema (e.g. it does not support multiple values for
typefield). We would be in much better shape if we ask for the OpenAPI spec of the custom resource. In that way, we can just aggregate the Spec with current OpenAPI spec and kubectl and other tools can use that to validate the resource. If we accept a JSON Schema, it would not be possible to convert it to OpenAPI if user provides any incompatible values for that Schema.@nikhita, @sttts @lavalamp