mirrors/turboprop
1
0
Fork 0
mirror of https://git.sr.ht/~goorzhel/turboprop synced 2024-12-14 11:37:37 +00:00
Code Activity

Write ADR 2

Browse source
This commit is contained in:
Antonio Gurgel 2023-12-03 13:50:44 -08:00
parent 2ad1ad92cd
commit dda6ce376f
2 changed files with 79 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
adr/1.md
View file

@ -51,24 +51,17 @@ services = flakeBuilders.services self.serviceData {
I do instead:
```nix
stages = [
services/0-istio
services/1-kyverno
services/2-longhorn
services/3-registry-cache
services/4-metallb
<...>
];
stages = (ls ./services);
serviceData = rake.leaves stages;
serviceData = rake.stages stages;
# This should return a list of unbuilt service trees.
```
I'm not sure what to do past this point but I know what I want:
1. `services/0-istio` is built by flakeBuilders.services with `apiVersions = []`.
2. `services/1-kyverno` is built by flakeBuilders.services with `apiVersions = [<Istio APIs>]`.
3. `services/2-longhorn` is built by flakeBuilders.services with `apiVersions = [<Istio APIs> <Kyverno APIs>]`.
1. `services/00-istio` is built by flakeBuilders.services with `apiVersions = []`.
2. `services/01-kyverno` is built by flakeBuilders.services with `apiVersions = [<Istio APIs>]`.
3. `services/02-longhorn` is built by flakeBuilders.services with `apiVersions = [<Istio APIs> <Kyverno APIs>]`.
4. And so on, until `services/XX-services` is built with all APIs accumulated from previous stages.
It looks like a `pkgs.lib.lists.foldl`. Also, the stages can be gathered with `ls ./services | filter(<starts with number>)`.
It looks like a `pkgs.lib.lists.foldl`.

73
adr/2.md Normal file
View file

@ -0,0 +1,73 @@
# ADR 2: Using directory trees as data
In `a2abba2` or sometime around then, I borrowed Nixhelm's [leaf-raking paradigm](https://github.com/farcaller/nixhelm/blob/e0383f7c11000f8c141a7d26197ee402424b017d/flake.nix#L9-L23) (and named it after [Digga's](https://github.com/divnix/digga/blob/baa54f8641ee9128cdda8b508553284c331fc9f1/src/importers.nix#L61-L114)...although this is the first time I'm looking directly at it, and now I'm realizing I could have just borrowed that very code.)
Example input and output, using `kubernetes@2de43d7`:
```
services
├── cert-manager
│   └── cert-manager
│   ├── default.nix
│   └── prometheusrule.yaml
├── cnpg-system
│   └── cloudnative-pg
│   └── default.nix
...
system
├── argo
│   └── workflows
│   └── default.nix
├── cert-manager
│   └── cert-manager
│   ├── default.nix
│   └── k8s-intermediate.sops.yaml
├── cnpg-system
│   └── cloudnative-pg
│   └── default.nix
```
```nix
systemServiceData = rake.leaves ./system;
serviceData = rake.leaves ./services;
```
```nix
serviceData = {
# These two derivations consist only of resources
# (`ClusterIssuer`, CNPG `Cluster`); the applications themselves
# are installed in `system`.
cert-manager.cert-manager = {lib, ...} -> {builder, args};
cnpg-system.cloudnative-pg = {lib, ...} -> {builder, args};
...
};
systemServiceData = {
argo.workflows = {charts, lib, user, ...} -> {builder, args, extraObjects};
cert-manager.cert-manager = {charts, lib, user, ...} -> {builder, args, extraObjects};
cnpg-system.cloudnative-pg = {charts, lib, ...} -> {builder, args};
...
};
```
Raking a service tree like this reduces the need to litter the source tree with
`default.nix` files (as seen in, e.g., [nixos-hardware](https://github.com/NixOS/nixos-hardware/tree/a89745edd5f657e2e5be5ed1bea86725ca78d92e)).
However, it imposes assumptions about the source tree that ADR 1 rendered invalid.
## Considered Options
### Adapt existing code
The most work.
### Borrow Digga's code
It's MIT-licensed, hence compatible with this project's Apache 2.
### Use Haumea
In reading about Digga's deprecation I was tipped off to Haumea.
It does exactly what I want: map a filesystem tree to an attrset.
## Decision
Use Haumea.