novox/mesh-lab
7
0
Fork 0
Code Issues Pull Requests 1 Releases Wiki Activity

Register R92 as a bed: genesis on a runtime that trusts no registry (hq issue 92) — NOT PROVED, blocked by issue 146 #85

Merged
mesh-admin merged 2 commits from fix/92-replay into main 2026-10-13 03:49:20 +00:00
Conversation 2 Commits 2 Files Changed 5
+462 -2
mesh-admin commented 2026-10-12 15:12:19 +00:00
Contributor
Copy Link
Copy Source

Replay of hq issue 92 (genesis pushed the control plane's image to a registry the container runtime did not yet trust). The fix is mesh-host #91, merge dd9ab7927d967e236ef755bbe5fd6238d68f10df. Reviews 73 and 76 on that pull request asked for this bed.

What

  • scenarios/genesis-untrusted.yml: an anchor (192.0.2.10) and a forge machine (192.0.2.30) that serves the pinned controller over git's protocol.
  • test/integration/replay92.test.ts: the base image pre-trusts the documentation ranges (src/lifecycle/base.ts). The bed removes that trust from the anchor (daemon.json removed, docker restarted before genesis) and checks with docker info that only loopback is trusted. It then runs mesh-bootstrap with --registry 192.0.2.10:5000. It asserts three things: the push is not refused ("server gave HTTP response to HTTPS client"), genesis gets past its publish step, and the registry serves mesh-controller:genesis. It also checks that the runtime trusts anchor.internal:5000. If genesis stops before its registry step, the test skips with the reason.
  • replays: a new kind, bed. The prover builds mesh-host and mesh-bootstrap at each commit. It builds the carried builder from the pinned controller (mesh-controller 3cfc121, on golang:<go.mod release>-alpine) and raises the bed with the pinned catalogue (c5e1bc7). A skipped bed counts as an error, never as "fails". The register test checks that a bed names its file and pins the controller and the catalogue.

NOT PROVED: do not merge yet

go run ./cmd/prove --repos ~/projects/novox R92 on g14 (incus works: mesh-lab check passes):

R92 (issue 92): NOT PROVED — before its fix error, on its fix error
  before/after: the bed skipped: R92 NOT REACHED: genesis stopped at step 6 of 24, verify ... the container "temp-mesh-controller" is running and the control plane in it does not answer

The cause is hq issue 146 (the foundation cannot be raised on the bus the mesh runs on), not this bed:

  • with examples/foundation-first-node.lock, the temporary controller crash-loops: "this control plane has no MESH_BUS_NATS, so it cannot reach the mesh's bus";
  • with examples/foundation-first-node-nats.lock, the installer refuses at step 4: "the template names no "guest:guest@" connection".

So no genesis at mesh-host main gets as far as its registry step against today's controller. Up to that point the bed works: the forge serves, the trust is removed and read back, the installer loads its builder, and the controller is built from 3cfc1216 inside the anchor. Once 146 is fixed, re-run the prover and update the pins (and the bundle the prover passes) if they need it.

Tested

  • sh merge-check.sh: 161 unit tests pass; replays vet and TestEveryReplayIsWhole pass.
  • The prover run above (about 20 min, both sides).

Replay for issue 92. Not ready to merge until it reads PROVED.

Replay of hq issue 92 (genesis pushed the control plane's image to a registry the container runtime did not yet trust). The fix is mesh-host #91, merge dd9ab7927d967e236ef755bbe5fd6238d68f10df. Reviews 73 and 76 on that pull request asked for this bed. ## What - scenarios/genesis-untrusted.yml: an anchor (192.0.2.10) and a forge machine (192.0.2.30) that serves the pinned controller over git's protocol. - test/integration/replay92.test.ts: the base image pre-trusts the documentation ranges (src/lifecycle/base.ts). The bed removes that trust from the anchor (daemon.json removed, docker restarted before genesis) and checks with docker info that only loopback is trusted. It then runs mesh-bootstrap with --registry 192.0.2.10:5000. It asserts three things: the push is not refused ("server gave HTTP response to HTTPS client"), genesis gets past its publish step, and the registry serves mesh-controller:genesis. It also checks that the runtime trusts anchor.internal:5000. If genesis stops before its registry step, the test skips with the reason. - replays: a new kind, bed. The prover builds mesh-host and mesh-bootstrap at each commit. It builds the carried builder from the pinned controller (mesh-controller 3cfc121, on golang:<go.mod release>-alpine) and raises the bed with the pinned catalogue (c5e1bc7). A skipped bed counts as an error, never as "fails". The register test checks that a bed names its file and pins the controller and the catalogue. ## NOT PROVED: do not merge yet `go run ./cmd/prove --repos ~/projects/novox R92` on g14 (incus works: `mesh-lab check` passes): R92 (issue 92): NOT PROVED — before its fix error, on its fix error before/after: the bed skipped: R92 NOT REACHED: genesis stopped at step 6 of 24, verify ... the container "temp-mesh-controller" is running and the control plane in it does not answer The cause is hq issue 146 (the foundation cannot be raised on the bus the mesh runs on), not this bed: - with examples/foundation-first-node.lock, the temporary controller crash-loops: "this control plane has no MESH_BUS_NATS, so it cannot reach the mesh's bus"; - with examples/foundation-first-node-nats.lock, the installer refuses at step 4: "the template names no \"guest:guest@\" connection". So no genesis at mesh-host main gets as far as its registry step against today's controller. Up to that point the bed works: the forge serves, the trust is removed and read back, the installer loads its builder, and the controller is built from 3cfc1216 inside the anchor. Once 146 is fixed, re-run the prover and update the pins (and the bundle the prover passes) if they need it. ## Tested - `sh merge-check.sh`: 161 unit tests pass; replays vet and TestEveryReplayIsWhole pass. - The prover run above (about 20 min, both sides). Replay for issue 92. Not ready to merge until it reads PROVED.
mesh-admin commented 2026-10-12 15:12:33 +00:00
Author
Contributor
Copy Link
Copy Source

Delivery novox/mesh-lab@0714f7a50933 — delivered since 2026-10-13T03:49:44Z

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

Transitions

  • 2026-10-13 01:00 (new) → proposed (announced): novox/mesh-lab#85's head announced
  • 2026-10-13 01:07 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
  • 2026-10-13 01:07 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
  • 2026-10-13 01:07 ready → proposed (trunk moved): out of date: judged against trunk 51fa3a73ab, the trunk is now 6ba65a12f218; judged again on a recheck or when it is merged
  • 2026-10-13 03:37 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
  • 2026-10-13 03:37 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
  • 2026-10-13 03:49 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 03:49 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-delivery:view --> **Delivery** `novox/mesh-lab@0714f7a50933` — **delivered** since 2026-10-13T03:49:44Z **Delivery plan** — builds nothing: the change touches no module of the mesh's graph **Transitions** - 2026-10-13 01:00 (new) → proposed (announced): novox/mesh-lab#85's head announced - 2026-10-13 01:07 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit - 2026-10-13 01:07 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail - 2026-10-13 01:07 ready → proposed (trunk moved): out of date: judged against trunk 51fa3a73ab3d, the trunk is now 6ba65a12f218; judged again on a recheck or when it is merged - 2026-10-13 03:37 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit - 2026-10-13 03:37 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail - 2026-10-13 03:49 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 03:49 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`.
jschoubben added 2 commits 2026-10-13 01:00:19 +00:00
Register R92 as a bed: genesis on a runtime that trusts no registry (hq issue 92) d03f87b00d 
The lab's base image trusts the documentation ranges as plain-HTTP registries, so no genesis bed could
see the push to an untrusted registry that issue 92 is about (reviews 73 and 76 on mesh-host #91). The
bed takes that trust off the anchor before the installer runs and asks the runtime it trusts loopback
only, then runs genesis with --registry 192.0.2.10:5000 and holds that the control plane reaches the
registry, trusted by the mesh's name too.

The prover gains a bed kind: it builds the node-engine and its installer at each commit, the carried
builder from the pinned controller, and raises the bed; a bed that never reached the step it replays
skips, and a skip is an error, never the fault reproduced.

Not proved yet: genesis stops at step 6 on both sides, because the temporary controller has no
MESH_BUS_NATS and the bus template is refused by the installer (issue 146).
Pin R92 to today's genesis: main with every genesis fix, and the same without #91 (hq issue 92)
mesh/merge-gate head 0714f7a50933 merged into trunk 6ba65a12f218 — pass: the change touches no module of the mesh's graph
Details
mesh/repo-check head 0714f7a50933 merged into trunk 6ba65a12f218 — pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (typescript)…
Details
mesh/delivery delivered
Details
0714f7a509 
At the fix's merge no genesis got past step 6 (issue 146), so neither side of the replay reached the
push it replays. Fix is mesh-host main 0d11b4fc; Before is that main with #91 reverted, on the
unmerged branch replay/r92-before; the controller and catalogue at their mains on both sides.
jschoubben force-pushed fix/92-replay from 4d2ee33bd2 to 0714f7a509 2026-10-13 01:00:19 +00:00 Compare
mesh-admin commented 2026-10-13 01:07:18 +00:00
Author
Contributor
Copy Link
Copy Source

Merge check at 0714f7a5: head 0714f7a509 merged into trunk 51fa3a73ab, pass

Out of date when it landed: out of date: judged against trunk 51fa3a73ab, the trunk is now 6ba65a12f218; judged again on a recheck or when it is merged

**Merge check** at `0714f7a5`: head 0714f7a50933 merged into trunk 51fa3a73ab3d, pass **Out of date when it landed**: out of date: judged against trunk 51fa3a73ab3d, the trunk is now 6ba65a12f218; judged again on a recheck or when it is merged
mesh-admin left a comment
Author
Contributor
Copy Link
Copy Source

Verdict: approve at 0714f7a509

Independent review of R92, the replay of issue 92 (genesis trusts its registry before pushing; the fix is mesh-host #91).

No blocking finding. Before merging, both required checks must be rechecked: they read "out of date" against trunk 6ba65a12 and carry no verdict for this head on the current trunk.

What I checked:

  1. The before side adds nothing beyond the revert and one helper. mesh-host replay/r92-before (9e233e1d87569273b4ed353c450b0bd27d21039b) is one commit on top of main 0d11b4fc930d6723f3dc54dc173175f66fb6b3b3. I compared its diff against 0d11b4fc with #91's own diff (dd9ab792^1..dd9ab792). bootstrap.go, preflight.go, trust.go and trust_test.go are line for line the reverse of #91. The only other change is orUnknown added to phase3.go: 8 lines, the helper that trust.go used to hold and that other code still calls. The branch builds and passes go vet ./internal/bootstrap.
  2. The pins are as described. The register has Fix 0d11b4fc930d6723f3dc54dc173175f66fb6b3b3 and Before 9e233e1d87569273b4ed353c450b0bd27d21039b on mesh-host, mesh-controller pinned to 49102e1645c920e42e453caf0aa0746d2b93ce90 and mesh-catalog to f88e3452f8b8b285ed86e1fe93e1a153f71faada, the same on both sides. The register's comment says why the fix side is today's main and not #91's merge: at dd9ab792 no genesis got past step 6.
  3. The proof. I did not re-run the 60-minute lab, as briefed. The recorded output, "R92 (issue 92): PROVED — before its fix fails, on its fix passes; before: the runtime refused to push to 192.0.2.10:5000 over plain HTTP — the registry was not trusted before the push (stopped at step 10 of 24, publish)", matches the bed's first assertion message and its UP_TO_PUBLISH steps. A skip is read as an error by bedVerdict, so a bed that never reached the registry step cannot count as the fault reproduced.
  4. It keeps main's entries, and no rebase is needed. The branch is one merge behind main (it lacks ea24e78, R340), but it merges into main 6ba65a12 without conflict, and the merged register holds R166, R279, R412 and R340 as well as R92. On that local merge, go vet and go test in replays/ pass, and the repository's sh merge-check.sh passes (typecheck and the npm tests, then replays/ and asks/).
  5. The bed's Bed-kind check in register_test.go requires a test/integration/*.test.ts file and pins of both the controller and the catalogue. The scenario uses only RFC 5737 documentation addresses.

Non-blocking:

  • bedVerdict's failure-message regex picks the first error: line from the TAP output. If the before side ever fails in before() rather than in the test, the message it quotes may be that hook's. The skip path already covers the unreached cases, so this only affects wording.

Statuses at this head:

  • mesh/merge-gate: pending, "out of date: judged against trunk 51fa3a73ab, the trunk is now 6ba65a12f218; judged again on a recheck or when it is merged"
  • mesh/repo-check: pending, same wording
  • mesh/delivery: pending, "checking"
Verdict: approve at 0714f7a509332144df61978fd970fb281bb32c3b Independent review of R92, the replay of issue 92 (genesis trusts its registry before pushing; the fix is mesh-host #91). No blocking finding. Before merging, both required checks must be rechecked: they read "out of date" against trunk 6ba65a12 and carry no verdict for this head on the current trunk. What I checked: 1. The before side adds nothing beyond the revert and one helper. mesh-host replay/r92-before (9e233e1d87569273b4ed353c450b0bd27d21039b) is one commit on top of main 0d11b4fc930d6723f3dc54dc173175f66fb6b3b3. I compared its diff against 0d11b4fc with #91's own diff (dd9ab792^1..dd9ab792). bootstrap.go, preflight.go, trust.go and trust_test.go are line for line the reverse of #91. The only other change is `orUnknown` added to phase3.go: 8 lines, the helper that trust.go used to hold and that other code still calls. The branch builds and passes `go vet ./internal/bootstrap`. 2. The pins are as described. The register has Fix 0d11b4fc930d6723f3dc54dc173175f66fb6b3b3 and Before 9e233e1d87569273b4ed353c450b0bd27d21039b on mesh-host, mesh-controller pinned to 49102e1645c920e42e453caf0aa0746d2b93ce90 and mesh-catalog to f88e3452f8b8b285ed86e1fe93e1a153f71faada, the same on both sides. The register's comment says why the fix side is today's main and not #91's merge: at dd9ab792 no genesis got past step 6. 3. The proof. I did not re-run the 60-minute lab, as briefed. The recorded output, "R92 (issue 92): PROVED — before its fix fails, on its fix passes; before: the runtime refused to push to 192.0.2.10:5000 over plain HTTP — the registry was not trusted before the push (stopped at step 10 of 24, publish)", matches the bed's first assertion message and its UP_TO_PUBLISH steps. A skip is read as an error by `bedVerdict`, so a bed that never reached the registry step cannot count as the fault reproduced. 4. It keeps main's entries, and no rebase is needed. The branch is one merge behind main (it lacks ea24e78, R340), but it merges into main 6ba65a12 without conflict, and the merged register holds R166, R279, R412 and R340 as well as R92. On that local merge, `go vet` and `go test` in replays/ pass, and the repository's `sh merge-check.sh` passes (typecheck and the npm tests, then replays/ and asks/). 5. The bed's Bed-kind check in register_test.go requires a test/integration/*.test.ts file and pins of both the controller and the catalogue. The scenario uses only RFC 5737 documentation addresses. Non-blocking: - `bedVerdict`'s failure-message regex picks the first `error:` line from the TAP output. If the before side ever fails in `before()` rather than in the test, the message it quotes may be that hook's. The skip path already covers the unreached cases, so this only affects wording. Statuses at this head: - mesh/merge-gate: pending, "out of date: judged against trunk 51fa3a73ab3d, the trunk is now 6ba65a12f218; judged again on a recheck or when it is merged" - mesh/repo-check: pending, same wording - mesh/delivery: pending, "checking"
mesh-admin merged commit 0ca7a83e0b into main 2026-10-13 03:49:20 +00:00
mesh-admin deleted branch fix/92-replay 2026-10-13 03:49:21 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
mesh-admin
Labels
No items
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
jschoubben miel.truyen
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/mesh-lab#85