Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate custom resources without having to manually define modules for them #36

Open
khaled opened this issue Sep 26, 2023 · 4 comments

Comments

@khaled
Copy link

khaled commented Sep 26, 2023

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
@felixscheinost
Copy link
Contributor

felixscheinost commented Nov 8, 2023

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.

@adrian-gierakowski
Copy link
Contributor

@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.

@poelzi
Copy link

poelzi commented Dec 28, 2023

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.

@mibmo
Copy link

mibmo commented Oct 19, 2024

Any update on this? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants