jschoubben
5d6e8fbe7a
One name per thing, per the HQ glossary: the module/container/image/binary/repo becomes mesh-controller, the seat the-controller, and the store+broker pair the foundation (embedded base bundles, default template and example lock renamed with their go:embed directives). No behaviour change — a pure vocabulary rename. Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
57 lines
2.7 KiB
YAML
57 lines
2.7 KiB
YAML
# ONE MACHINE, AND EVERYTHING A MESH HAS TO BE. Nothing is handed to it.
|
|
#
|
|
# The common case, and the one worth getting right first: a person with a single machine runs the
|
|
# installer and ends up with a mesh that works. Not a mesh that *runs* — `17-raising-a-mesh` is
|
|
# careful about that difference, and so is this scenario. Genesis ends with a foundation, a registry,
|
|
# a built control plane and a builder, and a mesh in that state cannot produce anything and holds no
|
|
# record of what it has. Calling that "up" is how the catalogue came to be missing from a test for
|
|
# weeks without anything complaining.
|
|
#
|
|
# So the test driving this asks the harder question: can this machine, given nothing but a container
|
|
# runtime and the host binary, end up holding
|
|
#
|
|
# - a foundation and a registry it pulled from the internet,
|
|
# - a control plane it BUILT, and then rebuilt from its own repository through the module path,
|
|
# - a builder that takes work over the broker,
|
|
# - the shared base every module with code of its own stands on,
|
|
# - a store of its own — the foundation's is the control plane's own plumbing, not a provider,
|
|
# - a catalogue, so it can say what it has and what a change reaches,
|
|
# - and a module of its own, built, provisioned and running.
|
|
#
|
|
# **There is no `images:` key, and that is the whole point of this file.** The four-machine scenario
|
|
# next door loads thirty-four of the mesh's own images from the workstation because it does not
|
|
# build them — a shape no real installation has. Here nothing is loaded. What the machine holds it
|
|
# either pulled from the internet or made.
|
|
#
|
|
# 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: one-node-mesh
|
|
|
|
segments:
|
|
hosting:
|
|
kind: public
|
|
cidr: [192.0.2.0/24]
|
|
|
|
machines:
|
|
# The address matters: the foundation template names the broker at a fixed address, and a token
|
|
# carries that verbatim as the endpoint an enrolling node dials. With one machine, that machine
|
|
# must BE it, or the mesh hands out an endpoint nothing answers on.
|
|
#
|
|
# Sized for what it actually does: the store, the broker, the registry, two control planes during
|
|
# the pivot, the builder, a Node toolchain and an npm cache in the build workspace, and then every
|
|
# core module it builds and runs on top of that.
|
|
anchor:
|
|
at: { segment: hosting, address: [192.0.2.10] }
|
|
egress: true
|
|
inbound: allow
|
|
memory: 12GiB
|
|
cpus: 6
|
|
disk: 60GiB
|
|
|
|
place:
|
|
all: [host, runtime]
|