search

hall / kubenix

Kubernetes management with Nix
https://kubenix.org/
MIT License
319 stars 30 forks source link

Remove assumption that custom resources have a spec field #35

Open khaled opened 1 year ago

khaled commented 1 year ago

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.

hall commented 1 year ago

Looks and sounds right to me; configMap and secret objects don't have a spec field so it's not unreasonable that CRs might not either.