Files
mesh-host/examples/README.md
T
jochen bc2a448512
mesh/merge-gate head bc2a4485122c merged into trunk 7a41e120635b — pass: the change touches no module of the mesh's graph
mesh/repo-check head bc2a4485122c merged into trunk 7a41e120635b — pass: its merge-check.sh passed
mesh/delivery delivered
Raise genesis's bus where the nats module keeps it, so adopting it keeps it (hq issue 590, ADR 0333)
The bundle raised the bus as mesh-broker on docker volumes; the catalogue's nats module keeps it as
mesh-broker-nats on directories of the machine, so the broker step refused rather than raise a second
bus, and genesis stopped at step 18 of 24.

The bundle now raises mesh-broker-nats with its configuration and user list in /var/lib/nats-module/conf,
its streams in /var/lib/mesh-broker-nats and its certificate in /var/lib/mesh-broker-tls, published on the
node's bus port. The broker step holds that layout to the module's manifest field by field before
registering anything, says the one restart onto the module's image, and waits until the bus runs that image
and its monitor answers. The installer's bridge writes the composed users at the module's bus-users path and
signals mesh-broker-nats. The bundle's bus configuration and user list are seeds, so a re-run after the
adoption does not put the bundle's one user back over the module's.
2026-10-13 02:09:03 +02:00

2.4 KiB

Examples

foundation-first-node.lock

The one genesis bundle (novox/hq ADR 0331): what a machine must be before a mesh exists — the bootstrap in novox/hq 07-the-foundation.md, whole, on the bus the mesh runs on:

0  a container runtime, and a filter before anything listens
1  the store runs
2  a database per context        `inventory`, `identity` and `licences`
3  those contexts' schemas       mesh-controller migrate
4  the bus's certificate         mesh-controller broker certificate
5  the bus runs                  NATS as mesh-broker-nats, where the nats module keeps it
                                 (ADR 0333), with the controller's account as its first user
6  the control plane runs        mesh-controller serve, given the bus (MESH_BUS_NATS)

A machine that applies this is a mesh — one node, with nothing joined to it yet, which is exactly what the first node is (novox/hq ADR 0004). From here it hands out tokens and everything else joins the ordinary way.

It is a template: mesh-bootstrap reads it, makes the store's superuser and the controller's account on the bus, and writes them where the template says bootstrap (internal/bootstrap, rootsecrets.go). A template whose bus connection it does not recognise is refused at preflight, naming the placeholder it looked for. The bundle that raised the previous broker was deleted with ADR 0331; there is one bundle, and every lab bed names it.

The bus is raised where the nats module keeps it (novox/hq ADR 0333): the container mesh-broker-nats, its configuration and user list in /var/lib/nats-module/conf, its streams in /var/lib/mesh-broker-nats, its certificate in /var/lib/mesh-broker-tls, published on the node's bus port. At the installer's broker step the module adopts it: its own image replaces the upstream one, once, on the same streams, users and certificate. internal/bootstrap holds the bundle to the module's manifest.

Build an installer carrying a builder, and point it at this:

make bootstrap IMAGE=<builder image>
mesh-bootstrap --bundle examples/foundation-first-node.lock …

The registry address is the lab's. The images are written as 192.0.2.250:5000/…@sha256:…; the lab rewrites the third-party ones to upstream references by the same digest, and the installer replaces the control plane's with the image it built.