The first three steps of the substrate bootstrap, run on a lab machine confirmed to have no route out. It went from bare to a container runtime installed and enabled, PostgreSQL running from an image pinned by digest, and the control plane's database created inside it -- from the file the host carries, with nothing to ask. Second run changed nothing. `owned` lists all five afterwards, and `mesh` is in the store. It stops before the last two steps because there is no control plane yet: its schema cannot be loaded and its image does not exist. The bundle says so rather than naming something that cannot be applied. Two things fixed on the way. `make host BUNDLE=...` still swapped a file called substrate.lock, which the per-system split had renamed months of decisions ago -- it now takes SYSTEM and replaces that system's bundle. And the .lock files still cited ADR 0060, since the renumbering pass only covered .md, .go, .ts and .sh. One thing learned by it failing first: a directory the host creates is owned by root, and a database inside a container runs as somebody else, so it could not write and the container crash-looped. The store's data is a named volume now, which lets the image set up its own ownership and outlives the container -- which is what you want for the thing holding the mesh's state. Worth noting the failure was caught by the action's verify rather than by the container step. `docker inspect` reported the container running because it was, briefly, between restarts. Running is not working, and the thing that knew the difference was the step that asked the database whether it would answer.
1.1 KiB
Examples
substrate-first-node.lock
What an Arch machine must be before a mesh exists — the first steps of the bootstrap in
novox/hq 07-the-substrate.md: a container runtime, a store
running, and the control plane's database created inside it.
It stops there, and the file says why: loading the control plane's schema and starting the control plane are the next two steps, and there is no control plane yet. A bundle naming one would be a bundle that cannot be applied.
Build a host carrying it:
make host SYSTEM=arch BUNDLE=examples/substrate-first-node.lock
The image reference has to be replaced before this is useful. It is written as
REGISTRY/postgres@DIGEST because the digest belongs to whatever registry serves it — in the
lab, one the 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.
Verified end to end in a lab machine with no route out: five resources applied, idempotent on a
second run, and mesh present in the store afterwards.