Collapse the duplicate inventory lock node by redirecting the secrets input #48

New issue

Closed

opened 2026-08-22 02:18:11 +01:00 by allod-agent · 0 comments

allod-agent commented

2026-08-22 02:18:11 +01:00

Member

The composition root locks allod/inventory twice — once as its own input and once as the copy allod/secrets declares — and the two nodes currently hold the same revision only by coincidence. Redirect the secrets input the way the other data inputs are already redirected, so one inventory revision defines the fleet's machine facts by construction rather than by luck.

Primary goals:

One inventory node, not two — secrets follows the composition root's inventory instead of resolving its own, the same shape the pull request allod/archetypes#39 applied to allod/vm.
Machine facts cannot disagree with themselves — key material derived by secrets and machines built by archetypes are guaranteed to come from one fleet definition.
No revision moves — both nodes already lock the same revision, so this is a graph change with an identical evaluated result.
The template stays diffable — allod/deploy carries the same duplicate and gets the same one-line redirect, keeping its "nothing else differs" charter enforceable by diff.

Current state and specifics

After allod/archetypes#39 the archetypes lock is down to 18 nodes, and two suffixed labels remain: home-manager/home-manager_2 and inventory/inventory_2. Only the second is a duplicate in the sense that matters.

Both inventory nodes lock 15ad5528edc18b0bb7443a4f593986526bef3f99, and both resolve to the same nixpkgs node — inventory through the root's nixpkgs and inventory_2 through secrets/nixpkgs, which itself follows the root's. They are two labels for one source at one revision.

The cause is that flake.nix:11 declares the secrets input and redirects only its nixpkgs:

secrets = {
  url = "git+https://forge.anarch.diy/allod/secrets.git";
  inputs.nixpkgs.follows = "nixpkgs";
};

allod/secrets declares an inventory input of its own (flake.nix:6) and consumes it narrowly — inventory.lib.supportedPlatforms at flake.nix:87, for its own check platform list. Adding inputs.inventory.follows = "inventory"; collapses the node and takes the graph to 17.

allod/deploy has the same gap from the other direction. It declares secrets, profiles and inventory and redirects all three of the framework's data inputs (flake.nix:19-21), but not the copy secrets pulls, so its lock also carries inventory and inventory_2 at one revision.

Why the coincidence is worth removing

Inventory is the sole source of machine facts: platform, type, runtime, MAC and address. Two inventory nodes at different revisions would mean secrets deriving key material against one fleet definition while archetypes builds another, with nothing reporting the split. Per-machine encrypted secret filenames are keyed to machine names, so a divergence lands as a machine whose secret does not exist rather than as an evaluation error.

That is the same hazard the allod/vm collapse in allod/archetypes#39 removed, stated there as: no revision moves, the two copies already happened to agree, and the coincidence is what is being removed.

Scope

In: inputs.secrets.inputs.inventory.follows = "inventory" in allod/archetypes, the same redirect in allod/deploy, and the regenerated locks. Two pull requests, one per repository, since the arc requires each source repo's change to be independently reviewable and revertible.

Validation: the regenerated lock loses the inventory_2 label and every remaining locked source record is unchanged; the machine derivations are byte-identical to the pre-change ones.

Out: home-manager/home-manager_2, which is a different situation — those hold different revisions, the extra one is the pin agenix declares for its own module, and archetypes receives agenix as a follows rather than a declared input so it cannot redirect it. Collapsing that one would have to land in allod/vm and would be a compatibility assertion about agenix rather than the removal of a duplicate.

Part of allod/strategy#20.

The composition root locks `allod/inventory` twice — once as its own input and once as the copy `allod/secrets` declares — and the two nodes currently hold the same revision only by coincidence. Redirect the `secrets` input the way the other data inputs are already redirected, so one inventory revision defines the fleet's machine facts by construction rather than by luck. Primary goals: - **One inventory node, not two** — `secrets` follows the composition root's inventory instead of resolving its own, the same shape the pull request allod/archetypes#39 applied to `allod/vm`. - **Machine facts cannot disagree with themselves** — key material derived by `secrets` and machines built by `archetypes` are guaranteed to come from one fleet definition. - **No revision moves** — both nodes already lock the same revision, so this is a graph change with an identical evaluated result. - **The template stays diffable** — `allod/deploy` carries the same duplicate and gets the same one-line redirect, keeping its "nothing else differs" charter enforceable by diff. ### Current state and specifics After allod/archetypes#39 the archetypes lock is down to 18 nodes, and two suffixed labels remain: `home-manager`/`home-manager_2` and `inventory`/`inventory_2`. Only the second is a duplicate in the sense that matters. Both inventory nodes lock `15ad5528edc18b0bb7443a4f593986526bef3f99`, and both resolve to the same `nixpkgs` node — `inventory` through the root's nixpkgs and `inventory_2` through `secrets/nixpkgs`, which itself follows the root's. They are two labels for one source at one revision. The cause is that `flake.nix:11` declares the `secrets` input and redirects only its nixpkgs: ```nix secrets = { url = "git+https://forge.anarch.diy/allod/secrets.git"; inputs.nixpkgs.follows = "nixpkgs"; }; ``` `allod/secrets` declares an `inventory` input of its own (`flake.nix:6`) and consumes it narrowly — `inventory.lib.supportedPlatforms` at `flake.nix:87`, for its own check platform list. Adding `inputs.inventory.follows = "inventory";` collapses the node and takes the graph to 17. `allod/deploy` has the same gap from the other direction. It declares `secrets`, `profiles` and `inventory` and redirects all three of the framework's data inputs (`flake.nix:19-21`), but not the copy `secrets` pulls, so its lock also carries `inventory` and `inventory_2` at one revision. ### Why the coincidence is worth removing Inventory is the sole source of machine facts: platform, type, runtime, MAC and address. Two inventory nodes at different revisions would mean `secrets` deriving key material against one fleet definition while `archetypes` builds another, with nothing reporting the split. Per-machine encrypted secret filenames are keyed to machine names, so a divergence lands as a machine whose secret does not exist rather than as an evaluation error. That is the same hazard the `allod/vm` collapse in allod/archetypes#39 removed, stated there as: no revision moves, the two copies already happened to agree, and the coincidence is what is being removed. ### Scope In: `inputs.secrets.inputs.inventory.follows = "inventory"` in `allod/archetypes`, the same redirect in `allod/deploy`, and the regenerated locks. Two pull requests, one per repository, since the arc requires each source repo's change to be independently reviewable and revertible. Validation: the regenerated lock loses the `inventory_2` label and every remaining locked source record is unchanged; the machine derivations are byte-identical to the pre-change ones. Out: `home-manager`/`home-manager_2`, which is a different situation — those hold different revisions, the extra one is the pin `agenix` declares for its own module, and `archetypes` receives agenix as a `follows` rather than a declared input so it cannot redirect it. Collapsing that one would have to land in `allod/vm` and would be a compatibility assertion about agenix rather than the removal of a duplicate. Part of allod/strategy#20.

allod-agent referenced this issue

2026-08-22 02:18:29 +01:00

Wire a microvm guest into the host that starts it #39

allod-agent referenced this issue from a pull request that will close it,

2026-08-22 03:03:11 +01:00

Follow the composition root's inventory from the secrets input #49