kubernetes.api.resources options generated as a result of specifying kubernetes.customTypes config values currently assume that the custom types have a spec field.
Though it may be convention, AFAIK it is not a requirement that CRD's have such a field. Here's an example in the wild. And currently there is no clean way to specify different toplevel options such as configuration from the provided example.
FWIW I was able to add additional toplevel options using kubernetes.api.defaults, though this is verbose and probably not its intended use, and as such I consider it an ugly hack :-)
More importantly, AFAICT there is no way to prevent a spec value of {} from showing up in the output, which is invalid if the CRD doesn't have spec in its schema.
kubernetes.api.resources
options generated as a result of specifyingkubernetes.customTypes
config values currently assume that the custom types have aspec
field.Though it may be convention, AFAIK it is not a requirement that CRD's have such a field. Here's an example in the wild. And currently there is no clean way to specify different toplevel options such as
configuration
from the provided example.FWIW I was able to add additional toplevel options using
kubernetes.api.defaults
, though this is verbose and probably not its intended use, and as such I consider it an ugly hack :-)More importantly, AFAICT there is no way to prevent a
spec
value of{}
from showing up in the output, which is invalid if the CRD doesn't havespec
in its schema.