jschoubben
1bc97ed50d
Because a running service does not re-read its configuration. Replace the file, find the service running, do nothing -- and the machine keeps behaving as it did while every check passes, because the file is right and the service is up. That is not hypothetical. It is how a third node joining a mesh left the first two carrying a private network that no longer existed, with every part of it reporting success. Declared state rather than a command: the declaration says the running service must reflect these files, and the host works out that it does not. A command to restart would be an action, and the link may not carry one -- the host refused precisely that when I tried it, correctly, which is how this shape was arrived at rather than the other. Scoped to one apply. A change from an earlier one has already been reflected, and restarting for it every time would make a steady machine bounce its services for ever. Also: the node generates its overlay key at enrolment and reports the public half, and the store waits three minutes rather than one for the database -- sixty seconds is not enough for a cold machine running initdb, and it failed that way three times, which is the worst kind of flake because a second run always fixed it.
Examples
substrate-first-node.lock
What a machine must be before a mesh exists — steps 0 to 4 of the bootstrap in
novox/hq 07-the-substrate.md:
0 a container runtime
1 the store runs
2 a database per context one today, `inventory`
3 that context's schema mesh-control migrate
4 the broker runs
It stops there, and the file says why. Step 5 is a virtual host, a credential and a certificate; step 6 is the control plane running. Nothing consumes any of them yet, and a bundle whose last step cannot be checked is worse than a shorter one.
Build a host carrying it:
make host SYSTEM=arch BUNDLE=examples/substrate-first-node.lock
The registry address and digests have to be replaced before this is useful. They are written
as 192.0.2.250:5000/…@sha256:… because a digest belongs to whatever registry serves it — here,
one a lab scenario raises, which reports its digests when it comes up. That is not a placeholder
to be tidied away: a bundle is built for a target, and which registry that target pulls from is
part of the target.
What was verified, and how
On a lab machine confirmed sealed — curl https://example.com times out, the lab registry answers
200 — the whole bundle applied from bare: eight resources, inventory created and mesh nowhere,
the node table present with its indexes, the migration recorded, and LavinMQ answering
lavinmqctl status with AMQP listening on 5672.
Three consecutive reconciles after that: already matches — 8 resource(s) checked, each time.
Then the machine was rebooted, and everything came back: docker from boot: enabled, both
containers because the host creates every container --restart unless-stopped
(internal/apply/apply.go), the schema intact in its named volume, and reconcile still finding
nothing to do.
The reboot is worth doing rather than assuming. Nothing in the declaration asks for a container to return, so that it does is a property of the host, and the only way to know it holds is to take the machine away and give it back.