Cleaner resolution for the problem mentioned last commit.
Fixes mono-namespace charts while assuming multi-namespace charts
have the diligence to set `.metadata.namespace` everywhere necessary.
In 0fb8e4d I forgot that flake input-following exists. I don't _have_ to
ship nixhelm myself, but I do need to include it so I can stop bundling
data for an oudated AT version.
In fact, I need not bundle _anything_ for the AT library to be useful;
it's better to make the builder's `chart` arg mandatory and let the user
supply their own (usually taken from nixhelm). If they get bored of
supplying the chart to every AT instance they can factor it out,
as I have in my own deployment.
In fact, my deployment relies on the AT library, which I used to provide
as a flake output -- but it didn't make sense to have one version of the
turboprop library available inside service definitions and another
available outside. So I've made the whole library a flake output.
This may bite me in the future.
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.
I stowed my particularities in lib.eureka, but exporting
`packages.*.flakeBuilders` with a pre-pressed `lib` left no way to put
the Eureka module back in. After further consideration, I decided
it's wise to keep `lib` that way instead of commingling it with
homelab data.
Getting away from manually pressing Helm charts (while, importantly, retaining
integrity checking and determinism) is something I liken to the
transition from sail to flight as the primary mode of intercontinental
travel. As it were, ditching the helm for a yoke.
"Helm releases" is what I'd been terming individual services, but
it makes no sense outside of the internal context of the Helm builder.
I also didn't want to call them "apps", however shorter that term is.
These are not apps.
I've changed release modules' signatures from:
`{lib} -> ... -> <drv>`
to:
`{lib} -> ... -> {out=<drv>; extra=<drv>;}`
Which makes individual derivations more easily findable.
Now, instead of picking them out from a soup of paths in `output.sh`
with a specially-crafted needle (`${ns}-${name}`), I map derivations
directly to paths and use the result as a sort of index. In other words,
I spent some ingenuity in `flake-builders.sh` to save a _lot_ of
ingenuity in `output.sh`.
This affords me the extra convenience, previously spurned because of
the very limitation I've overcome, of symlinking derivations in the
output flake.
I have my answer to 2638113, and it's what I was suspecting: the
flake-builder was never using clusterData until I added a release
that needs it, at which point I got the dreaded "error: attribute
'apiVersions' missing".
Remediation was simple: realize the wrongheadedness of passing
an empty attrset when the values are already well-known.
Line 62 of this commit's flake.nix should bail with an attribute-missing
error while evaluating `buildDerivations.releases`, at the point where
Nix tries to inherit two variables from an empty `clusterData`.
...Or is it that I will have problems when I add something using
lib.builders.helmChart to `./system`? I'll only find out tomorrow.
