Closed blaggacao closed 1 year ago
Why? How? It looks like yet more kubernetes yaml madness. Does this look like kubenix
consuming kustomization resources now too and converting them to Nix, or something else? Are there actually folks trying to use Nix... and the kustomize ecosystem? I have a hard time imagining that user.
Why? How? It looks like yet more kubernetes yaml madness.
I suspect there will be an emerging/converging White Box Application ecosystem. It would be useful for kubenix to capture this configuration database and enable users to employ the power of nix/nickel for overlays.
So the intention of this suggestion is:
Are there actually folks trying to use Nix... and the kustomize ecosystem?
I think we first need to acknowledge the myriad of potential impacts of kustomize now being merged fully into kubectl in terms of an emerging standard for off-the-shelf k8s configs.
I'm comparing kubenix + nix to kpt
+ kustomize
.
quick notes to self (eventually expanding):
kpt
→ inputs.X.url = ...?/dir=path/to/deploydir
kustomize
→ nix
It would be appropriate for kubenix to load kustomize
projects out in the wild, render them with kustomize and make them available for modification with nix a la lib.revursiveUpdate
(but with a little extra implementation of the k8s native merge strategies for associative arrays and arrays in general).
This repo has been deprecated, since I stopped maintaining it some time ago. There is a fork maintained by @hall available at https://github.com/hall/kubenix, that has better documentation and looks like a way further.
The k8s ecosystem is starting to catch up with it's deficiencies over nix.
https://kubectl.docs.kubernetes.io/guides/app_deployment/publishing_bases/
This means, it wold be tremendously useful if
kubenix
could hook into White Box Application concept, yet allow users to customize according to accustomed nix's powers.