Code change:
"spec.version[v1].schema.openAPIV3Schema.properties[d]: Required value: because it is defined in spec.version[v1].schema.openAPIV3Schema.not.properties[d]", }, }, <ins> { desc: "metadata with non-properties", globalSchema: ` type: object properties: metadata: minimum: 42.0 `, expectedViolations: []string{ "spec.validation.openAPIV3Schema.properties[metadata]: Forbidden: must not specify anything other than name and generateName, but metadata is implicitly specified", "spec.validation.openAPIV3Schema.properties[metadata].type: Required value: must not be empty for specified object fields", }, }, { desc: "metadata with other properties", globalSchema: ` type: object properties: metadata: properties: name: pattern: "^[a-z]+$" labels: type: object maxLength: 4 `, expectedViolations: []string{ "spec.validation.openAPIV3Schema.properties[metadata]: Forbidden: must not specify anything other than name and generateName, but metadata is implicitly specified", "spec.validation.openAPIV3Schema.properties[metadata].type: Required value: must not be empty for specified object fields", "spec.validation.openAPIV3Schema.properties[metadata].properties[name].type: Required value: must not be empty for specified object fields", }, }, { desc: "metadata with name property", globalSchema: ` type: object properties: metadata: type: object properties: name: type: string pattern: "^[a-z]+$" `, expectedViolations: []string{}, }, { desc: "metadata with generateName property", globalSchema: ` type: object properties: metadata: type: object properties: generateName: type: string pattern: "^[a-z]+$" `, expectedViolations: []string{}, }, { desc: "metadata with name and generateName property", globalSchema: ` type: object properties: metadata: type: object properties: name: type: string pattern: "^[a-z]+$" generateName: type: string pattern: "^[a-z]+$" `, expectedViolations: []string{}, }, { desc: "metadata under junctors", globalSchema: ` type: object properties: metadata: type: object properties: name: type: string pattern: "^[a-z]+$" allOf: - properties: metadata: {} anyOf: - properties: metadata: {} oneOf: - properties: metadata: {} not: properties: metadata: {} `, expectedViolations: []string{ "spec.validation.openAPIV3Schema.anyOf[0].properties[metadata]: Forbidden: must not be specified in a nested context", "spec.validation.openAPIV3Schema.allOf[0].properties[metadata]: Forbidden: must not be specified in a nested context", "spec.validation.openAPIV3Schema.oneOf[0].properties[metadata]: Forbidden: must not be specified in a nested context", "spec.validation.openAPIV3Schema.not.properties[metadata]: Forbidden: must not be specified in a nested context", }, }, </ins> } for i := range tests {

Related discussion:
text: We allow CRD authors to write . Currently we don't restrict writing validation for , which means people can have . For example, people can have additive name constraints (require CR to be ) with the following schema: This brings us two questions: do we if "metadata" is included in the schema: simplest option is to publish standard metav1.ObjectMeta schema info, and use any CRD-specified "metadata" properties as additive validation (just like in-tree types do, publishing standard ObjectMeta schema info, and implementing type-specific name validation internally) alternatively, we can try merging user-specified metadata schema with the standard one. Technically people should only add extra validation to existing metadata properties (adding new fields to metadata won't work since they will be pruned by built-in validation first), but it's unclear to me how arbitrary people may want the metadata validation to be term question is whether to allow people specifying metadata validation at all, or just allow a subset (like name validation) in CRD v1 /sig api-machinery /area custom-resources cc
What is the difference between these two? I mean the end result is the same right? The only thing that can be is validation. Nothing else works unless you are considering extensions?
The former means we drop/hide user-specified metadata schema when we publish CRD OpenAPI. We still validate user-specified constraints on server side, but client-side validation won't see them. The latter enables client-side user-specified metadata validation.
If it's possible to merge with standard metadata schema info, or at the cost of not publishing the standard schema. My inclination would be to publish the complete standard schema for metadata/apiVersion/kind, which we know is complete and accurate, and use and user-specified schema for those fields as addition validations server side