The documentation for pkgs.lib.lists.unique warned me that the function
is O(n^2). So I conducted some rather unscientific tests using my own
Kubernetes flake and found no noticeable time penalty:
`rm result && nix-collect-garbage -d && nix build` always took
between 37 and 40 seconds, with or without gatherNamespaces.
But, well, n=10.
Also, make more obvious the flaw in mk.namespaces.
If I prefix something with "N.B." it shouldn't be hidden in the code.
This interface was getting ridiculous.
`app-template` gets released infrequently enough that keeping a static
`chart.nix` is a small tradeoff for the previous lunacy of passing a
whole derivation tree in through the flake.
`apiVersions` gave me a headache while writing the foldl so I made it
a separate input.
Now the service modules have this signature, without my having to
change any code in the modules themselves:
{charts, etc, ...} -> [apiVersion] -> {out, extra}
Two imperfections have come to bite me simultaneously:
- I wanted strict ordering of services but implemented it very sloppily.
- The flake builders represent implementation leakage. I want to present
a clean interface to users, not "first, you must evaluate these
twenty-eight variables".
So now I'm fixing too many things at once. Luckily it's hard to lose
things in Git.
Also, I had a brief temptation to move `gatherApis` to `flake-builders`,
but apart from being used in the flake's let-in, it has little in common
with the other builders. I need to lose a direct dependency on kubelib
to try the concept out, though (`flake-builders` doesn't take `kubelib`),
and I ended up keeping the result.
My long-term vision for this flake is to use it as a control flake:
plug it into your homelab ("data-plane") flake and avail yourself
of its `lib.builders`, et cetera.
In short, I want this flake to be useful to many people, and that
means not shipping my homelab with it.
- Moved external ServiceEntry generator to `lib.resources`.
- Gave it some company: a generator of HTTPRoutes for gateway/svc.
- Gave `lib.vars.svcGateway` a parentRef generator, at the cost of
another level of recursion, and some variable renaming.
Everything I need directly from nix-kube-generators is now
handled in `lib/`. Additionally, now that I know buildYAMLStream always
takes a namespace and name, there's no need for the longer-winded name.
The reason I struggled with genericBuilders, and again when I replaced
`remoteYAML`'s NS-name `pname` with `url`, is that I was confusing the
following two things:
1. Things that fetch a resource (a Helm chart, a YAML stream, etc.)
without naming or namespacing it.
2. Things that create a release _by_ giving it a name and namespace
so that lib/output.sh can sort the resultant files into directories.
Additionally, I was questioning the good sense of releases/svc/gateway:
a release with no release, but only extra objects? Turns out I
needlessly bound the concept of JIT namespace injection to that
`extraObjects` feature. Once I abstracted that builder, the more general
solution became clear.
By declaring builders at the module level, only to call them in
flake.nix, I give myself the opportunity to inject `{name, namespace}`
there and need no longer pass these args into every module myself.
NixOS configs taught me wrong; `imports=[]` is not a magic sequence.
But because `lib/default.nix` returns an attrset, I can use attrset
mechanics on it.
charts/ and src/ both have two levels of children:
- charts/$repo/$chart
- src/$ns/$release
So, why not use one function to rake them both?
Also, the leaf-raking doesn't require nixpkgs or nix-kube-generators so
I moved everything that does (e.g.: `downloadCharts`) into the
`eachDefaultSystem` part of the output, following the example of
nixhelm's flake.
