Validate custom resources without having to manually define modules for them
Currently, if custom resources are being used, they have to be specified manually using kubernetes.customTypes. \
Furthermore, custom resources won't be validated at build time without manually defining a nix module in kubernetes.customTypes.*.module. This is redundant since CRDs already define the schema.
It would be nice to not have to do any of the above. Some potential avenues:
- Generate nix module types automatically during build, or provide a tool that does so (the former would probably require IFD?)
- Use a tool such as kubeconform to validate resources
I am currently using IFD to achieve that. I am not sure how I exactly I came up with it but it works for my usecase: https://gist.github.com/felixscheinost/9e7fc4370fe1ce2dfbe6efb0e75d4f4f
How I use is that I have a folder with only CRDs and other folders for other manifests which make use of those manifests:
- crds
- kube-prometheus-stack.nix
- apps
- kube-prometheus-stack.nix
- some-other-app.nix
Both crds/kube-prometheus-stack.nix and apps/kube-prometheus-stack.nix would load the kube-prometheus-stack Helm chart. But the one in the crds folder could have an empty values as it actually is only needed for the CRDs.
apps/kube-prometheus-stack.nix then contains the actual configuration for the Helm chart.
All files in apps can make use of the CRDs defined in crds but the modules in crds folder can't make use of CRDs.
@felixscheinost thanks for sharing! Given that kubenix uses IFD for helm charts already I don’t think using it the way you have is a problem. I guess this could be adapted to not use IFD if the CRD schemas are known in advance.
Alternatively we could use the python-openapi and add some nix templates to generate nix options for any openapi spec. The problem with kubeconform will be, to map the output to the nix input line since it will operate on the processed output. Having a nix type based definition will yield better error messages without loops and hurdles.
I need CRDs for rook, kubevirt and some other CDRs. Maybe the istio generator can be generalized enough for easier adding more CDRs.
Any update on this? :)