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.
`mkDerivation` doesn't have to be assigned beforehand; it can just be
passed two attrsets. I only realized this after writing out its
signature in the documentation.
Also, the example flake in the documentation doesn't use nixpkgs,
so I removed it.
`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 try to insert line breaks where a thought fragment ends (a habit
learnt from writing subtitles), but in comments and Git commit
messages it doesn't make as much sense.
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.
kubelib.buildHelmChart can take the target Kubernetes version and
a list of custom APIs, so I'll bind them both up in an attrset
and pass them to `flake-builder.releases`.
Accordingly, the other release-builders will have to become variadic.
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.
Packages can either output new APIs or expect them in the cluster.
Examples of packages which
- output APIs: Gateway API, which installs various versions of
gateway.networking.k8s.io resources.
- take APIs as input: app-template, which queries the cluster to
choose v1a2, v1b1, or v1 for its HTTPRoute (etc.) objects.
("Packages" here collectively refers to Helm charts and YAML bundles.)
I will have to impose strict ordering on them, i.e., build the former
before the latter.
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.
