Phase 3 closed — the store and broker are ordinary modules, issue 051 fixed

Marks WBS 3.2/3.3/3.4 done and resolves issue 051: the foundation's store and
broker are adopted in place as the postgres and lavinmq modules, upgradeable
through their stated windows, source-tracked by status. A bare-metal mesh runs
one postgres and one lavinmq, proven 22/22 in the one-node lab. The two follow-up
gaps are tracked as issues 054 and 055.

Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
This commit is contained in:
2026-09-16 23:07:03 +02:00
parent fcf3b6f4d5
commit 0073e52881
2 changed files with 30 additions and 8 deletions
+13 -5
View File
@@ -87,11 +87,19 @@ a protocol that agrees, a registry to publish to. Issue 051.
binds `0.0.0.0` from genesis so a mesh consumer can reach it, but the packet filter is binds `0.0.0.0` from genesis so a mesh consumer can reach it, but the packet filter is
installed later — a brief pre-filter window where `mesh-store` is open before `from: mesh` installed later — a brief pre-filter window where `mesh-store` is open before `from: mesh`
clamps it; bring the filter up earlier or bind narrower at genesis.)* clamps it; bring the filter up earlier or bind narrower at genesis.)*
- [ ] 3.2 the broker is adopted — one `lavinmq`, the `/` vhost for the mesh bus, a vhost per - [x] 3.2 the broker is adopted — one `lavinmq`, the `/` vhost for the mesh bus, a vhost per
consumer that requires `amqp`; the second server gone consumer that requires `amqp`; the second server gone. *(Adopted in place like the store; the
- [ ] 3.3 an upgrade of each, proven: a store the controller reads from, a broker over the module names mesh-broker with the foundation's TLS spec, the provisioner runs host-networked
broker, each with a stated window as lavinmq's default guest, amqp-ping reaches it. Proven 22/22.)*
- [ ] 3.4 `status` can say the foundation is behind its source, which today it cannot form - [x] 3.3 an upgrade of each, proven: a store the controller reads from, a broker over the
broker, each with a stated window. *(Lab steps S1/S2: move each module's source, build, roll
out, then a full push applies the server change and recreates the container. The store's
window is a pool reconnect; the broker's is longer — recreating the bus the push travels over,
so the mesh reconnects to the one that returns. Data survives on the named volumes.)*
- [x] 3.4 `status` can say the foundation is behind its source, which today it cannot form.
*(Given by the adoption: postgres/lavinmq are ordinary modules with a source now, so
`module list`/`status` reports them behind or current like any other — the question could
not form when they were bundle containers.)*
**Done when.** A mesh built from bare metal runs one postgres and one lavinmq, and can upgrade **Done when.** A mesh built from bare metal runs one postgres and one lavinmq, and can upgrade
either — so the twelve-module floor has no specialty left in it. either — so the twelve-module floor has no specialty left in it.
@@ -1,8 +1,8 @@
--- ---
status: open status: fixed
opened: 2026-09-14 opened: 2026-09-14
located-in: [] located-in: [mesh-host, mesh-catalog]
fixed-by: fixed-by: mesh-host 56124c3; mesh-catalog 5e4dc37; mesh-lab 440e265
amended-design: amended-design:
--- ---
@@ -117,3 +117,17 @@ broker upgrade is the mesh asking the machine to replace the thing the request a
| The mesh can say its substrate is out of date | The store's source moves and `status` reports it behind, the way it does for any module. | | The mesh can say its substrate is out of date | The store's source moves and `status` reports it behind, the way it does for any module. |
| The mesh can deliver a substrate update | A store or broker is upgraded on a running mesh and the control plane is answering afterwards, with its records intact. | | The mesh can deliver a substrate update | A store or broker is upgraded on a running mesh and the control plane is answering afterwards, with its records intact. |
| Nothing runs twice without a reason | A mesh with one machine runs one postgres unless somebody asked for two. | | Nothing runs twice without a reason | A mesh with one machine runs one postgres unless somebody asked for two. |
## Resolution
The foundation's store and broker are adopted in place as the ordinary `postgres` and `lavinmq`
modules (WBS Phase 3). Each module declares the container the foundation raised — the same name,
image, ports, volumes and args — so the applier reconciles it rather than raising a second server;
`mesh-host`'s `InstallStore` (phase3.go) carries in the genesis credentials the mesh cannot invent.
The servers bind mesh-wide so consumers reach them, and their provisioners run host-networked. An
upgrade of each is proven through its stated window — the store's a pool reconnect, the broker's the
harder case of recreating the bus the push travels over — and `status` now reports both as ordinary
modules that can be behind their source. A mesh built from bare metal runs one postgres and one
lavinmq, proven 22/22 in the one-node lab. Two follow-ups are tracked: [054](../054-the-adopted-store-and-broker-are-open-before-the-filter/00-report.md)
(the pre-filter exposure window) and [055](../055-the-adopted-store-and-broker-may-be-reachable-on-one-node-only/00-report.md)
(multi-node reachability).