Raise genesis's store as the postgres module's server, so the store step adopts it as it runs (issue 609, hq ADR 0338) #104

2026-10-13T08:48:32Z

mesh-admin commented

2026-10-13 08:48:32 +00:00

Issue 609 (genesis stops at step 17: the postgres module declares no container named mesh-store). Decision: hq ADR 0338, accepted and approved by the operator.

What

Bundle (§1): the store is raised as postgres, on the module's image pgvector/pgvector@sha256:cf134a…, pinned by the module's own reference with no lab prefix. Its data is in /var/lib/mesh-store, made 0700 999:70 by a new directory resource before the store starts. The superuser password comes from the module's own-secret file through POSTGRES_PASSWORD_FILE, as before via rootsecrets.go.
Every step names postgres (§2): the store's readiness and database actions, the schemas, the packages step's gitea database (foundationStore) and the store step's message.
The refusal to raise a store over data it cannot open looks for a cluster at /var/lib/mesh-store/pgdata/PG_VERSION, no longer for the volume mesh-store-data (§2).

Tests (fail with main's bundle)

TestTheBundleRaisesTheStoreAsTheCataloguesPostgresModuleDeclaresIt reads the catalogue's own postgres manifest (MESH_CHECK_BESIDE, else beside, else a loud skip). Name, image, PGDATA, password file, mounts and ports must equal the module's, so this is the drift test of §1; the store step's own serverMatchesFoundation must accept it.
TestTheBundleMakesTheStoresDataDirectoryAsTheModuleDoes and TestNoStepReachesTheStoreByTheSeatsName.
TestTheRefusalOverExistingDataLooksInTheStoresDirectory: a cluster in the directory is refused, and only the old volume is not.
The port tests (§4) already cover a non-default store port.
merge-check.sh passes. There is no nats-server here, so the bus tests are skipped, and the script says so.

The measurement (§5) is mesh-lab's PR for issue 609, a replay-side test. On g14 at 07:3x, pgvector initialised a store that answers with the file's password, on a directory made 999:70 0700 (PostgreSQL 17.11).

The bed (§5): not run yet. It should pass the store step without recreating the store and reach the broker step.

Fixes issue 609 (bed proof outstanding).

Issue 609 (genesis stops at step 17: the postgres module declares no container named mesh-store). Decision: hq ADR 0338, accepted and approved by the operator. **What** - Bundle (§1): the store is raised as `postgres`, on the module's image `pgvector/pgvector@sha256:cf134a…`, pinned by the module's own reference with no lab prefix. Its data is in `/var/lib/mesh-store`, made 0700 999:70 by a new directory resource before the store starts. The superuser password comes from the module's own-secret file through `POSTGRES_PASSWORD_FILE`, as before via rootsecrets.go. - Every step names `postgres` (§2): the store's readiness and database actions, the schemas, the packages step's gitea database (`foundationStore`) and the store step's message. - The refusal to raise a store over data it cannot open looks for a cluster at `/var/lib/mesh-store/pgdata/PG_VERSION`, no longer for the volume `mesh-store-data` (§2). **Tests (fail with main's bundle)** - `TestTheBundleRaisesTheStoreAsTheCataloguesPostgresModuleDeclaresIt` reads the catalogue's own postgres manifest (MESH_CHECK_BESIDE, else beside, else a loud skip). Name, image, PGDATA, password file, mounts and ports must equal the module's, so this is the drift test of §1; the store step's own `serverMatchesFoundation` must accept it. - `TestTheBundleMakesTheStoresDataDirectoryAsTheModuleDoes` and `TestNoStepReachesTheStoreByTheSeatsName`. - `TestTheRefusalOverExistingDataLooksInTheStoresDirectory`: a cluster in the directory is refused, and only the old volume is not. - The port tests (§4) already cover a non-default store port. - merge-check.sh passes. There is no nats-server here, so the bus tests are skipped, and the script says so. **The measurement (§5)** is mesh-lab's PR for issue 609, a replay-side test. On g14 at 07:3x, pgvector initialised a store that answers with the file's password, on a directory made 999:70 0700 (PostgreSQL 17.11). **The bed (§5)**: not run yet. It should pass the store step without recreating the store and reach the broker step. Fixes issue 609 (bed proof outstanding).

mesh-admin added 1 commit 2026-10-13 08:48:33 +00:00

Raise genesis's store as the postgres module's server, so the store step adopts it as it runs (hq issue 609, ADR 0338)

mesh/merge-gate head 4dde21f0ab20 merged into trunk 7d1d6bffe30c — pass: the change touches no module of the mesh's graph

Details

mesh/repo-check head 4dde21f0ab20 merged into trunk 7d1d6bffe30c — pass: its merge-check.sh passed

Details

mesh/delivery delivered

Details

4dde21f0ab

The bundle raised the store as mesh-store, on upstream postgres, in a docker volume; the postgres
module keeps it as postgres, on its pgvector image, in /var/lib/mesh-store owned 999:70, reading its
superuser password from a file. The store step refused, and genesis stopped at step 17 of 24.

The bundle now raises the store with the module's name, image, data directory and password file, and
every step of the bundle and the installer reaches it by that name. The refusal to raise a store over
data it cannot open looks for a cluster in the store's directory, no longer for the old volume.

mesh-admin commented

2026-10-13 08:48:56 +00:00

Delivery novox/mesh-host@4dde21f0ab20 — delivered since 2026-10-13T08:55:48Z

Delivery plan — builds nothing: the change touches no module of the mesh's graph

Transitions

2026-10-13 08:48 (new) → proposed (announced): novox/mesh-host#104's head announced
2026-10-13 08:50 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
2026-10-13 08:50 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
2026-10-13 08:55 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
2026-10-13 08:55 published → delivered (done): nothing for a walk to move

The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.

**Delivery** `novox/mesh-host@4dde21f0ab20` — **delivered** since 2026-10-13T08:55:48Z **Delivery plan** — builds nothing: the change touches no module of the mesh's graph **Transitions** - 2026-10-13 08:48 (new) → proposed (announced): novox/mesh-host#104's head announced - 2026-10-13 08:50 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit - 2026-10-13 08:50 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail - 2026-10-13 08:55 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move - 2026-10-13 08:55 published → delivered (done): nothing for a walk to move The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.

mesh-admin reviewed

2026-10-13 08:55:17 +00:00

mesh-admin left a comment

Verdict: approve at 4dde21f0ab

Statuses at this head: mesh/merge-gate success ("head 4dde21f0ab merged into trunk 7d1d6bffe3 — pass: the change touches no module of the mesh's graph"), mesh/repo-check success ("head 4dde21f0ab merged into trunk 7d1d6bffe3 — pass: its merge-check.sh passed"), mesh/delivery success ("ready: it delivers once merged").

No blocking findings.

What I ran, with mesh-catalog main 5cd608b and mesh-controller main beside the checkout (MESH_CHECK_BESIDE): go vet ./... is clean; go test -race ./internal/bootstrap/ passes; go test -race ./... passes; merge-check.sh exits 0.

The four new tests fail on main. I copied store_layout_test.go onto main with only the StoreDataDir constant added so it compiles, and all four fail for the right reasons: the store is named mesh-store, the image is the lab's postgres, the mounts are mesh-store-data, the store step's serverMatchesFoundation refuses ("the postgres module declares no container named mesh-store"), no directory is made before the store, five mesh-store references are found, and a cluster in /var/lib/mesh-store is not refused. Without the constant they do not compile on main at all.

Field by field against mesh-catalog main's modules/postgres (server and store-data resources): the name (postgres), the image (pgvector/pgvector@sha256:cf134a76...), PGDATA, POSTGRES_PASSWORD_FILE, the two volumes (with ${dir:state} as /var/lib/postgres), the ports (5432:5432) and the data directory (/var/lib/mesh-store, 0700, 999:70) are equal. The bundle carries no POSTGRES_PASSWORD after RewriteRoot. The module also declares a tcp health check and a dumps subdirectory, which the bundle does not. The applier's container spec (image, name, env, ports, volumes, args, hosts, dns, networks, capabilities) does not include health, so I do not expect that difference to recreate the store at adoption. Whether anything the controller adds when it renders the module moves the spec is not shown by any unit test here; that is the bed's job under ADR 0338 §5, and the bed has not run yet.

An existing installation's store cannot be wiped by this change. I checked a re-run on a machine that still holds the old mesh-store container and its mesh-store-data volume with a scratch test against CheckTheMachine and RefuseExistingServers (removed afterwards):

With the old mesh-store running on 5432, genesis is refused at the bundle step by the port check, before anything is applied: "the store's port tcp/5432 is held by the container mesh-store ... nothing was changed". RefuseExistingServers itself no longer refuses, as ADR 0338 §2 decides.
With the old mesh-store stopped, genesis is not refused. The store resource keeps its id (store) and only its target moves; State.Record makes a former record only for a declared-origin resource, so the old container is not removed as an orphan, and docker rm never touches a named volume. The old data is left untouched, but a new, empty store is raised in /var/lib/mesh-store and the run says nothing about the old volume. The same happens if a person follows the port refusal's advice and gives --store-port. This matches ADR 0338 §2 ("one holding only the old volume is not" refused), so it is not blocking; consider a line in the run's output when mesh-store-data exists, saying it is left aside and not adopted.

Minor: RefuseExistingServers treats any failure of test -e as "no cluster there", including a permission error. Genesis runs as root, so this does not bite today, but a check that distinguishes exit status 1 from other failures would fail loudly instead of open.

The PR says the bed (ADR 0338 §5, store step without recreating the store, then the broker step) is outstanding; issue 609 should not be resolved until it has run.

Verdict: approve at 4dde21f0ab20ff6148e90d9103ac289026b9794d Statuses at this head: mesh/merge-gate success ("head 4dde21f0ab20 merged into trunk 7d1d6bffe30c — pass: the change touches no module of the mesh's graph"), mesh/repo-check success ("head 4dde21f0ab20 merged into trunk 7d1d6bffe30c — pass: its merge-check.sh passed"), mesh/delivery success ("ready: it delivers once merged"). No blocking findings. What I ran, with mesh-catalog main 5cd608b and mesh-controller main beside the checkout (MESH_CHECK_BESIDE): go vet ./... is clean; go test -race ./internal/bootstrap/ passes; go test -race ./... passes; merge-check.sh exits 0. The four new tests fail on main. I copied store_layout_test.go onto main with only the StoreDataDir constant added so it compiles, and all four fail for the right reasons: the store is named mesh-store, the image is the lab's postgres, the mounts are mesh-store-data, the store step's serverMatchesFoundation refuses ("the postgres module declares no container named mesh-store"), no directory is made before the store, five mesh-store references are found, and a cluster in /var/lib/mesh-store is not refused. Without the constant they do not compile on main at all. Field by field against mesh-catalog main's modules/postgres (server and store-data resources): the name (postgres), the image (pgvector/pgvector@sha256:cf134a76...), PGDATA, POSTGRES_PASSWORD_FILE, the two volumes (with ${dir:state} as /var/lib/postgres), the ports (5432:5432) and the data directory (/var/lib/mesh-store, 0700, 999:70) are equal. The bundle carries no POSTGRES_PASSWORD after RewriteRoot. The module also declares a tcp health check and a dumps subdirectory, which the bundle does not. The applier's container spec (image, name, env, ports, volumes, args, hosts, dns, networks, capabilities) does not include health, so I do not expect that difference to recreate the store at adoption. Whether anything the controller adds when it renders the module moves the spec is not shown by any unit test here; that is the bed's job under ADR 0338 §5, and the bed has not run yet. An existing installation's store cannot be wiped by this change. I checked a re-run on a machine that still holds the old mesh-store container and its mesh-store-data volume with a scratch test against CheckTheMachine and RefuseExistingServers (removed afterwards): 1. With the old mesh-store running on 5432, genesis is refused at the bundle step by the port check, before anything is applied: "the store's port tcp/5432 is held by the container mesh-store ... nothing was changed". RefuseExistingServers itself no longer refuses, as ADR 0338 §2 decides. 2. With the old mesh-store stopped, genesis is not refused. The store resource keeps its id (store) and only its target moves; State.Record makes a former record only for a declared-origin resource, so the old container is not removed as an orphan, and docker rm never touches a named volume. The old data is left untouched, but a new, empty store is raised in /var/lib/mesh-store and the run says nothing about the old volume. The same happens if a person follows the port refusal's advice and gives --store-port. This matches ADR 0338 §2 ("one holding only the old volume is not" refused), so it is not blocking; consider a line in the run's output when mesh-store-data exists, saying it is left aside and not adopted. Minor: RefuseExistingServers treats any failure of test -e as "no cluster there", including a permission error. Genesis runs as root, so this does not bite today, but a check that distinguishes exit status 1 from other failures would fail loudly instead of open. The PR says the bed (ADR 0338 §5, store step without recreating the store, then the broker step) is outstanding; issue 609 should not be resolved until it has run.

mesh-admin merged commit 17038b2a07 into main

2026-10-13 08:55:42 +00:00

mesh-admin deleted branch fix/609-genesis-raises-the-store-as-postgres

2026-10-13 08:55:42 +00:00

mesh-admin referenced this pull request

2026-10-13 09:00:19 +00:00

Wait until the node applied the genesis document before the sdk step asks for a build (issue 615) #105

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#104