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