Change:
changed = true } <ins> if s.XPreserveUnknownFields && s.Type == "object" { // similar as above, kubectl doesn't properly handle object fields with `x-kubernetes-preserve-unknown-fields: true` s.Type = "" changed = true } </ins> for f, fs := range s.Properties { if fs.Nullable { s.ValueValidation.Required, changed = filterOut(s.ValueValidation.Required, f)

Discussion:
What happened: I have CRD with a spec field of type and annotation . I want to store json data in this field which is actually a Grafana Dashboard json. When I try to create a CR of this type, I am getting validation error from json bytes. . In the json data . What you expected to happen: I expected no error since I set How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.17.0 Cloud provider or hardware configuration: kind OS (e.g: ): Ubuntu 18.04 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig api-machinery /area custom-resources
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: I have CRD with a spec field of type and annotation . I want to store json data in this field which is actually a Grafana Dashboard json. Kubernetes version (use ): v1.17.0 Cloud provider or hardware configuration: kind OS (e.g: ): Ubuntu 18.04 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig api-machinery /area custom-resouces Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
cc:
, you are able to create the CRD, which is also working for me. Are you able to create the CR for this CRD? Does the following command work for you?
Running the second command:
I think you have not read the issue clearly. The CRD creation is working fine. I am getting validation error when trying to create CR for this CRD.
I edited the previous comment with result for second command.
Thanks ! This is the issue I see. I expected no error since I set .
If you pass --validate=false, does it create successfully?
Yes, if I pass --validate=false, it creates successfully.
Then the issue is in client-side kubectl validation, and the server is behaving as expected
/cc for openapi validation
Yeah, we should probably make anything that has the accept anything.

I thought we already did so for types that are . Maybe this never landed actually, I could look it up.
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
That's probably not super hard to solve if someone wants to try.
A good way to start would be to solve all the TODOs in Or possibly, to address this bug specifically: This is the function that validates the "kind" (i.e. structures): When I initially wrote this code, we assumed that these type would never have additionalProperties. We probably need to change this condition since it's not really valid: and this one: We create the kind here: That function would have to be changed to save the "additionalProperties" type (if given) or the ability to have additionalProperties.
Actually, the problem also is that it doesn't know how to handle null. This one is a little tricky.
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
I think the publishing of the "object" type must be supressed for fields. We have similar cases already.

Touching kubectl is not very effective, or at least it takes multiple releases to makes its way through the ecosystem.
/assign