Description
In our API types we currently conceive 'Required' as meaning not optional.
Our optional types have the following definition:
An optional field MUST be marked with +optional and include an omitempty JSON tag. Fields SHOULD be pointers if there is a good reason for it, for example: the nil and the zero values (by Go standards) have semantic differences. Note: This doesn't apply to map or slice types as they are assignable to nil. the field is of a struct type, contains only fields with omitempty and you want to prevent that it shows up as an empty object after marshalling (e.g. kubectl get)
Currently with Kubernetes this is enough as fields not marked optional are required in CRDs.
We could be explicit with Optional vs Required in our API definitions by explicitly setting Required on the OpenAPI specs. This would make our API more explicit and holistic on the OpenAPI level.
You can also specify // +kubebuilder:validation:Optional on a package level, which then switches this defaulting round so that fields are optional if no tag is specified. If someone sets that on your package, it can be quite easy to miss, so it's better to be explicit about what you want on each field
Also the fact that any conceptually required field that you want to default needs to be declared optional for client side validation to not complain e.g kubectl, is suboptimal and confusing.
See the original discussion at: #6383 (comment)
@fabriziopandini @enxebre @JoelSpeed @sbueringer
/kind feature
/area api