jschoubben
bfd70e9e57
The scenario names no images and the bed rewrites nothing: the installer raises anchor (building the control plane), the mesh's own builder builds base, postgres, lavinmq and the joined node's consumers from the forge and pins every digest itself, the committed manifests are registered verbatim, and node2 proves both foundation halves cross-node. Being iterated toward green (run 3 in flight); banked so nothing is lost. https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
55 lines
2.3 KiB
YAML
55 lines
2.3 KiB
YAML
# TWO MACHINES, AND NOTHING FAKED. The no-fake multi-node gate.
|
|
#
|
|
# The one-node scenario proves a machine given nothing but a container runtime ends up with a mesh
|
|
# that BUILT everything it runs. This is its two-machine sibling, and the multi-node claim it adds
|
|
# is the one the rewrite-based beds could not honestly make: every image on either machine was
|
|
# pulled from the internet or built by the mesh's own builder — the bed rewrites nothing, pins
|
|
# nothing, stocks nothing. The builder is the only thing that ever turns a manifest's placeholder
|
|
# into a digest, exactly as in production.
|
|
#
|
|
# anchor is raised into a mesh of one by the installer, adopts the foundation store and broker as
|
|
# the postgres and lavinmq modules (built by the mesh), and node2 joins and runs the consumers —
|
|
# amqp-ping against the one broker, letta against the one store — over the overlay.
|
|
#
|
|
# **There is no `images:` key, and that is the whole point of this file.**
|
|
#
|
|
# EGRESS IS NOT OPTIONAL: with nothing loaded, a sealed machine stops at the installer's first pull.
|
|
#
|
|
# MESH_LAB_HOST_BINARY=.../mesh-host MESH_LAB_BOOTSTRAP_BINARY=.../mesh-bootstrap
|
|
# MESH_LAB_BUNDLE=.../examples/foundation-first-node.lock
|
|
# MESH_LAB_CATALOG=.../mesh-catalog/modules
|
|
# MESH_LAB_SOURCE=<forge url> MESH_LAB_SOURCE_REF=<commit>
|
|
scenario: built-store-cross-node
|
|
|
|
segments:
|
|
hosting:
|
|
kind: public
|
|
cidr: [192.0.2.0/24]
|
|
|
|
machines:
|
|
# The address matters: the foundation template names the broker at 192.0.2.10:5671, and a token
|
|
# carries that verbatim as the endpoint an enrolling node dials.
|
|
#
|
|
# Sized like the one-node anchor: store, broker, registry, two control planes during the pivot,
|
|
# the builder with a Node toolchain and npm cache, and the built module images on top.
|
|
anchor:
|
|
at: { segment: hosting, address: [192.0.2.10] }
|
|
egress: true
|
|
inbound: allow
|
|
memory: 12GiB
|
|
cpus: 6
|
|
disk: 60GiB
|
|
# The joined consumer node. It builds nothing — it pulls what the mesh's registry serves and what
|
|
# its modules name upstream (letta's app image comes from the internet, ~2GB), so it needs egress
|
|
# and room for images, not build horsepower.
|
|
node2:
|
|
at: { segment: hosting, address: [192.0.2.20] }
|
|
egress: true
|
|
inbound: allow
|
|
memory: 6GiB
|
|
cpus: 4
|
|
disk: 40GiB
|
|
|
|
place:
|
|
all: [host, runtime]
|