Open khaled opened 1 year ago
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:
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? :)
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: