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
31 lines
1.2 KiB
YAML
31 lines
1.2 KiB
YAML
# One machine, raising a foundation from the bundle its host carries.
|
|
#
|
|
# This is the bootstrap class (novox/hq ADR 0009): no forge, no control plane to talk to, no
|
|
# delivery. It exists to develop the steps of raising a mesh on a machine that has nothing but a
|
|
# connection — a container runtime, a store, the control plane's schema in it, and the broker.
|
|
#
|
|
# It stops before the control plane *runs*, because there is nothing for it to serve yet.
|
|
scenario: first-node
|
|
|
|
segments:
|
|
hosting:
|
|
kind: public
|
|
cidr: [192.0.2.0/24]
|
|
|
|
machines:
|
|
anchor:
|
|
at: { segment: hosting, address: [192.0.2.10] }
|
|
egress: true
|
|
inbound: allow
|
|
|
|
# The control plane's own image exists in no registry — it is built from source, and until this
|
|
# mesh has a registry of its own there is nowhere to have pushed it. So it is loaded onto the
|
|
# machine and named by the digest of its own configuration, which is exact and cannot move, which
|
|
# is what pinning asks for (novox/hq ADR 0006). The store and the broker are ordinary third-party
|
|
# images, and the machine pulls them from the internet like anything else.
|
|
images:
|
|
- mesh-controller:development
|
|
|
|
place:
|
|
all: [host, runtime]
|