Check that inventory guests, host keys and identities name one set of machines #48
No reviewers
Labels
No labels
blocked
bug
decision
duplicate
enhancement
handoff
help wanted
invalid
landed?
question
ready-to-merge
stale
wontfix
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
allod/secrets!48
Loading…
Reference in a new issue
No description provided.
Delete branch "agent/inventory-machine-sets"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Nothing changes on any running machine: this adds one check to the secrets gate and edits no data, lib output or deployed file. The check refuses a secrets tree whose machines disagree with the inventory: a guest with no entry in
machine-host-keys.json, an entry for a machine the inventory does not declare or for the primary hypervisor, a guest with no identity inidentity.nix, an identity for no guest, an identity filed under another machine type's attrset, or one name in two attrsets. Each refusal names the file to edit. Before this, the gate passed with a guest deleted from the host-key file and with an entry for a machine that does not exist, measured on this branch's parent; after it, both are refused by name. Proof is the gate on this branch (11 steps, 10 checks built) plus six sabotaged copies of the template's own data, each refused with the expected message, and two mutations of the check that its fixtures catch. If it is wrong, revert the one commit; nothing deployed depends on it. If a fork's legal layout trips it, the message says which name and which file, and the fork's fix is a data edit, not a framework change.Closes allod/secrets#43
What the issue got right and what it did not
The gap the issue describes is real in this repository and was measured: deleting
bitcoin-nodefrommachine-host-keys.jsontogether with its ciphertext left all 10 existing steps green, and so did adding an entry for a machine namedghost. Two claims in the issue are narrower than written.allod/archetypesalready asserts identity keys equal machine keys at composition, so the identity half is caught today, only late and in the wrong repository; andmkVmFactsin archetypes throws on a guest with no host-key entry, but only when something forcesvmFacts, which the deploy gate does not, so that failure surfaces atprovision-vmon the hypervisor. This check moves both refusals to the repository that owns the files and names them.Risk
R1. A check with no effect on any derivation a machine builds;
flake.nix,liboutputs and every data file are untouched. Worst credible failure after validation: a fork with a legal machine layout the fixtures did not anticipate is refused and its gate goes red until a data edit, which the message names. Rollback is a revert of one commit.Validation
allod checkon the branch:All 11 steps passed (checks: 10 built).machine-host-keys.json; guest with no identity; identity under the wrong attrset; identity for no machine.testing.md); the fleet can change without touching them.