A switch to take a declared template machine out of the build #67

New issue

Open

opened 2026-10-11 16:52:26 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-11 16:52:26 +01:00

Contributor

Primary goals:

One switch per machine — a declared machine can be marked off and then builds nothing, provisions nothing, and creates no image, while its definition, facts and identity stay in place for the day it is wanted.
Every consumer honours it — the framework's composed machines and vmFacts, the deploy gate (allod check instantiates every machine's toplevel today), the generated vm-specs.json that new-vm, provision-vm and verify-vm read, and the installer image's authorized keys.
Fail loud on a half-switch — a machine that is off but still referenced somewhere that cannot honour the switch is an evaluation error naming it, not a machine that quietly builds anyway.
Template default is on — the example fleet ships every machine on, so a fresh install is unchanged; a fork flips what it does not want.

Current state and specifics

A machine is three entries that must agree: an inventory entry (facts), a secrets identity (account, host key), and a profile definition (modules). The framework asserts the inventory's machine keys and the secrets' identity keys match exactly, so removing a machine today is a coordinated edit in two data repositories, and a fork that only wants to skip one machine has no smaller move. Everything downstream iterates the inventory: machineConfigurations and vmFacts in archetypes, the deploy gate, and the hypervisor scripts through vm-specs.json.

The trigger is the bitcoin node arriving in the template as a fourth machine (allod/profiles#14, allod/nexus#93, and the inventory and secrets entries tracked beside them). A laptop that runs the stack as a development box has no use for a node and should not evaluate one on every gate, nor have provision-vm able to create a 40 GB image for it by accident.

Default to decide: inventory is the source of truth for machine facts, so the switch most naturally lives there as a machine fact, with archetypes filtering on it before the key-match assertion and vm-specs.json either omitting the machine or carrying the flag for the scripts to refuse on. Alternatives (a profile-side flag; a deploy-flake override) are follow-ups unless the default fails.

Scope

This is the tracking issue for a multi-repo arc; children land in allod/inventory (the fact and its validation), allod/archetypes (the filter and the assertion), and allod/nexus (the scripts' handling). Out: changing what the template's machines are.

A fork that will never host one of the template's machines, the bitcoin node for instance, should be able to switch that machine off in one place and stop paying for it in evaluation, checks, provisioning and disk, instead of deleting its entries from two repositories. Primary goals: - **One switch per machine** — a declared machine can be marked off and then builds nothing, provisions nothing, and creates no image, while its definition, facts and identity stay in place for the day it is wanted. - **Every consumer honours it** — the framework's composed machines and `vmFacts`, the deploy gate (`allod check` instantiates every machine's toplevel today), the generated `vm-specs.json` that `new-vm`, `provision-vm` and `verify-vm` read, and the installer image's authorized keys. - **Fail loud on a half-switch** — a machine that is off but still referenced somewhere that cannot honour the switch is an evaluation error naming it, not a machine that quietly builds anyway. - **Template default is on** — the example fleet ships every machine on, so a fresh install is unchanged; a fork flips what it does not want. ### Current state and specifics A machine is three entries that must agree: an inventory entry (facts), a secrets identity (account, host key), and a profile definition (modules). The framework asserts the inventory's machine keys and the secrets' identity keys match exactly, so removing a machine today is a coordinated edit in two data repositories, and a fork that only wants to skip one machine has no smaller move. Everything downstream iterates the inventory: `machineConfigurations` and `vmFacts` in archetypes, the deploy gate, and the hypervisor scripts through `vm-specs.json`. The trigger is the bitcoin node arriving in the template as a fourth machine (allod/profiles#14, allod/nexus#93, and the inventory and secrets entries tracked beside them). A laptop that runs the stack as a development box has no use for a node and should not evaluate one on every gate, nor have `provision-vm` able to create a 40 GB image for it by accident. Default to decide: inventory is the source of truth for machine facts, so the switch most naturally lives there as a machine fact, with archetypes filtering on it before the key-match assertion and `vm-specs.json` either omitting the machine or carrying the flag for the scripts to refuse on. Alternatives (a profile-side flag; a deploy-flake override) are follow-ups unless the default fails. ### Scope This is the tracking issue for a multi-repo arc; children land in allod/inventory (the fact and its validation), allod/archetypes (the filter and the assertion), and allod/nexus (the scripts' handling). Out: changing what the template's machines are.

vnprc-agent referenced this issue from allod/inventory

2026-10-11 16:53:59 +01:00

Add the bitcoin-node machine to the template #26

vnprc-agent referenced this issue from allod/profiles

2026-10-11 16:58:50 +01:00

A bitcoin-node privacy machine in the template #14

vnprc-agent referenced this issue from allod/inventory

2026-10-11 16:58:50 +01:00

Add the bitcoin-node machine to the template #26

vnprc-agent referenced this issue

2026-10-12 01:46:22 +01:00

A bitcoin node a fork gets by provisioning it #68