Mark a machine's host-provided repos and render them into vm-specs.json #21

Closed
opened 2026-10-01 17:13:39 +01:00 by allod-agent · 0 comments
Member

A machine definition can name repos whose checkout the hypervisor supplies, so a dev VM whose forge identity may not read a remote keeps that repo in repos (which the framework's memory assert requires) while the guest bootstrap no longer tries to clone it.

Part of allod/strategy#62.

Primary goals:

  • A per-machine marker — a guest machine may declare host_provided_repos = [ "<registry id>" ... ], and every id named must also appear in that machine's repos.
  • Rendered into vm-specs.json — mkVmSpecsJson emits host_provided_repos for a machine that declares it and omits the key otherwise, so the consumer in allod/nexus (bootstrap-vm, allod/nexus#73) reads .host_provided_repos // [] and sees no change on a machine without the marker.
  • Validated with pinned diagnostics — a marker that is not a list of strings, a member outside the machine's repos, and a marker on a hypervisor each fail evaluation with their own diagnostic, disjoint from every other, with a mutation check that pins each sabotage to its one diagnostic the way host-fact-mutations does for host.
  • Template data unchanged — no public machine declares the marker, so scripts/vm-specs.json stays byte-identical and the vm-specs-json drift check still passes.

Current state and specifics

flake.nix mkVmSpecsJson whitelists the rendered fields (memory_mb vcpus disk_gb ip mac forge_key repos runtime, plus data_disk and host when declared), so an undeclared key never reaches the JSON. machineDiagnostics classifies a machine set into disjoint diagnostic sets, each guarded on the previous predicate, and mkVmSpecs asserts them in a stated order; host-fact-mutations is the check shape to copy for the new marker. The repository-registry check validates every repos member against scripts/repositories.json and already reads machineRepositoriesJson; the new marker's subset rule is a per-machine rule and belongs in machineDiagnostics, not in that shell check.

Scope

In scope: the marker's validation and rendering in flake.nix, one mutation check, and a line in README.md. Tracked elsewhere: the host step that injects and refreshes the checkout (allod/nexus#73), the guest-side skip rule for checkout walkers (the allod/tools child of allod/strategy#62), and deployments mirroring the marker in their private inventory forks.

A machine definition can name repos whose checkout the hypervisor supplies, so a dev VM whose forge identity may not read a remote keeps that repo in `repos` (which the framework's memory assert requires) while the guest bootstrap no longer tries to clone it. Part of allod/strategy#62. Primary goals: - **A per-machine marker** — a guest machine may declare `host_provided_repos = [ "<registry id>" ... ]`, and every id named must also appear in that machine's `repos`. - **Rendered into `vm-specs.json`** — `mkVmSpecsJson` emits `host_provided_repos` for a machine that declares it and omits the key otherwise, so the consumer in `allod/nexus` (`bootstrap-vm`, allod/nexus#73) reads `.host_provided_repos // []` and sees no change on a machine without the marker. - **Validated with pinned diagnostics** — a marker that is not a list of strings, a member outside the machine's `repos`, and a marker on a hypervisor each fail evaluation with their own diagnostic, disjoint from every other, with a mutation check that pins each sabotage to its one diagnostic the way `host-fact-mutations` does for `host`. - **Template data unchanged** — no public machine declares the marker, so `scripts/vm-specs.json` stays byte-identical and the `vm-specs-json` drift check still passes. ### Current state and specifics `flake.nix` `mkVmSpecsJson` whitelists the rendered fields (`memory_mb vcpus disk_gb ip mac forge_key repos runtime`, plus `data_disk` and `host` when declared), so an undeclared key never reaches the JSON. `machineDiagnostics` classifies a machine set into disjoint diagnostic sets, each guarded on the previous predicate, and `mkVmSpecs` asserts them in a stated order; `host-fact-mutations` is the check shape to copy for the new marker. The `repository-registry` check validates every `repos` member against `scripts/repositories.json` and already reads `machineRepositoriesJson`; the new marker's subset rule is a per-machine rule and belongs in `machineDiagnostics`, not in that shell check. ### Scope In scope: the marker's validation and rendering in `flake.nix`, one mutation check, and a line in `README.md`. Tracked elsewhere: the host step that injects and refreshes the checkout (allod/nexus#73), the guest-side skip rule for checkout walkers (the allod/tools child of allod/strategy#62), and deployments mirroring the marker in their private inventory forks.
vnprc closed this issue 2026-10-01 20:57:49 +01:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
allod/inventory#21
No description provided.