When building tooling that looks at CRDs or works with k8s yaml, understanding the types that are are being used is helpful for custom validations, rewrites, generation, and other rules.
In CRDs when someone references ObjectMeta, rather than getting all of ObjectMeta the CRD has a minimal representation, this was done in #557 (comment) which causes issues for our tooling when, specifically, PodTemplateSpec which contains ObjectMeta in it is used in some CRDs, this results in only parts of ObjectMeta being present in the resulting schema.
While we have a work around to look for the minimized structure of ObjectMeta that is written in CRDs, it's essentially a fuzzy match dependent on however the code-generator behaves, which isn't a reliable way to make tooling.
Rather than writing a minimized version of ObjectMeta, instead I propose adding a new type to the k8s schema that represents an embedded ObjectMeta that has a stronger guarantee of stability. For example MinimalObjectMeta or something which would be what is currently written in CRDs. This would allow for some level of stability for what we can expect in a schema where that occurs instead of needing to guess what fields the code-generator us using today if we want to apply custom tooling to ObjectMeta types.
This came up in part because the fields that are added are a mix of the fields from various sections in the docs about ObjectMeta https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/object-meta/ where initial thinking may be the non-service and writable fields would be available in CRDs but instead the mix leads to confusion which a named type would solve.
Related
https://github.com/kubernetes-sigs/controller-tools/pull/557/files#diff-d44a1fc23240ca1bdc8c22b4e23fe14ce4366bb1624542b417de0008d68a8e9aL115
kubernetes/kubernetes#103739
When building tooling that looks at CRDs or works with k8s yaml, understanding the types that are are being used is helpful for custom validations, rewrites, generation, and other rules.
In CRDs when someone references
ObjectMeta, rather than getting all ofObjectMetathe CRD has a minimal representation, this was done in #557 (comment) which causes issues for our tooling when, specifically,PodTemplateSpecwhich containsObjectMetain it is used in some CRDs, this results in only parts ofObjectMetabeing present in the resulting schema.While we have a work around to look for the minimized structure of
ObjectMetathat is written in CRDs, it's essentially a fuzzy match dependent on however thecode-generatorbehaves, which isn't a reliable way to make tooling.Rather than writing a minimized version of
ObjectMeta, instead I propose adding a new type to the k8s schema that represents an embeddedObjectMetathat has a stronger guarantee of stability. For exampleMinimalObjectMetaor something which would be what is currently written in CRDs. This would allow for some level of stability for what we can expect in a schema where that occurs instead of needing to guess what fields thecode-generatorus using today if we want to apply custom tooling toObjectMetatypes.This came up in part because the fields that are added are a mix of the fields from various sections in the docs about
ObjectMetahttps://kubernetes.io/docs/reference/kubernetes-api/common-definitions/object-meta/ where initial thinking may be the non-service and writable fields would be available in CRDs but instead the mix leads to confusion which a named type would solve.Related
https://github.com/kubernetes-sigs/controller-tools/pull/557/files#diff-d44a1fc23240ca1bdc8c22b4e23fe14ce4366bb1624542b417de0008d68a8e9aL115
kubernetes/kubernetes#103739