- Clarify nature of release paths.
- Explain why I haven't bothered to wedge values.yaml files into the
default derivation.
- Move drv_matcher to copy_drv_output, where it conceptually belongs.
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.
"Flake builder for charts could also take {fetcher, args}."
Except it shouldn't, because then I'll be peppering 98% of the modules
in `charts/` with `fetcher = lib.fetchers.helmChart`. Better to spend
a constant 100..150 chars on an extra flake-builder (fetchCharts) than
n*(30..50) chars on a refactor.
- 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.
