From 4a51ea4b3afaf129c81c8acee122806e52e997b1 Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 29 Sep 2026 15:25:58 +0200 Subject: [PATCH] Issue 146: the foundation cannot be raised on the bus the mesh runs on MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Found trying to run ADR 0147's bed. The older bundle raises the previous broker and a control plane that refuses to start without MESH_BUS_NATS; the newer one stops a step earlier, asking for a certificate from openssl in an image that has none. No bed can run while this holds, so 0147's check section now says what actually stands behind it — the rendering, not a machine. --- ...47-a-module-anchors-the-meshs-authority.md | 13 ++++ .../00-report.md | 73 +++++++++++++++++++ 2 files changed, 86 insertions(+) create mode 100644 04-ISSUES/146-the-foundation-cannot-be-raised-on-the-bus-the-mesh-runs-on/00-report.md diff --git a/02-DECISIONS/0147-a-module-anchors-the-meshs-authority.md b/02-DECISIONS/0147-a-module-anchors-the-meshs-authority.md index fc6fee7..e0e19a0 100644 --- a/02-DECISIONS/0147-a-module-anchors-the-meshs-authority.md +++ b/02-DECISIONS/0147-a-module-anchors-the-meshs-authority.md @@ -100,6 +100,19 @@ above has become right. the proxy serves. Those have their own beds, and this module's bed passing for those reasons is the failure mode this record is most exposed to — which is why the negative half is not optional. +**What this bed is dialled at, and why it is the authority itself.** The authority serves its own +API with a certificate it issued, so the handshake under test needs nothing else in the mesh to be +right. A trust bed that reached for a routed name through the proxy would be passing or failing for +the proxy's reasons and the resolver's. + +**Written, and not yet run** *(2026-09-29)*. The bed is `trust-anchor` in the lab, and it cannot +execute: raising a foundation fails before any module is reached, in both bundles that exist +([issue 146](../04-ISSUES/146-the-foundation-cannot-be-raised-on-the-bus-the-mesh-runs-on/00-report.md)). +So what stands behind this record today is the rendering — the script the machine would run names +the authority it was bound to, checked in the control plane's own test suite — and **not** a machine +that verified anything. That is a weaker thing than the paragraph above describes, and it stays +written this way until the bed runs. + ## Consequences The predecessor's authority can be retired from a machine once this module is assigned to it, diff --git a/04-ISSUES/146-the-foundation-cannot-be-raised-on-the-bus-the-mesh-runs-on/00-report.md b/04-ISSUES/146-the-foundation-cannot-be-raised-on-the-bus-the-mesh-runs-on/00-report.md new file mode 100644 index 0000000..f1b2059 --- /dev/null +++ b/04-ISSUES/146-the-foundation-cannot-be-raised-on-the-bus-the-mesh-runs-on/00-report.md @@ -0,0 +1,73 @@ +--- +status: open +opened: 2026-09-29 +located-in: [] +--- + +# 146 — the foundation cannot be raised on the bus the mesh runs on + +## What was observed + +Raising a first node in the lab, to check a module against a real mesh, fails before any module is +reached. Two separate faults, in the two bundles that exist: + +**The older bundle raises a control plane that cannot start.** It brings up the previous broker, +and the control plane it then starts says, once every few seconds, for ever: + +``` +mesh-controller: this control plane has no MESH_BUS_NATS, so it cannot reach the mesh's bus +``` + +That is the control plane being right. The mesh moved to one bus +([ADR 0131](../../02-DECISIONS/0131-everything-on-the-mesh-speaks-to-the-broker-seat.md)) and the +bundle did not. Every bed that raises a foundation raises this one, so every bed is in this state. + +**The newer bundle, written for the new bus, stops one step earlier.** Its certificate step asks a +container to make the broker's certificate: + +``` +docker run --rm --entrypoint sh -v :/tls \ + -c "test -f /tls/tls.crt || (openssl req -x509 ... )" +... +failed bus-certificate: running the action: docker exited 127 +``` + +127 is *command not found*. The bus's image has a shell and no `openssl`; the previous broker's +image had both, which is why the step worked when it was written against that one. Substituting the +store's image — the only other image the bundle carries — does not help: it has no `openssl` +either. So the step as written cannot succeed with anything the bundle names, and the fault is not +one image's: **the bundle asks for a certificate to be made by a tool it never says must be there.** + +Measured 2026-09-29 on a fresh lab machine, both bundles, from bare. + +## Why this is here and not a note in the knowledge base + +The mesh's own foundation is the one thing it cannot raise. Nothing reports that: the bundles are +files in a repository, nothing applies them but a person raising a node, and the last thing that +did was the hand-driven cut-over +([ADR 0131](../../02-DECISIONS/0131-everything-on-the-mesh-speaks-to-the-broker-seat.md), whose +work was done on the machines rather than from a bundle). So the state where the mesh cannot make +another one of itself is reachable, and was reached, without anything saying so. + +It is also load-bearing for everything else: a lab bed proves a claim by raising a mesh, so while +this holds, **no bed can run**, and every "checked in the lab" written from now on is a promise +against a suite nobody can execute. + +## What would have prevented it + +- **Something raising the foundation on a schedule, from the bundle, as it is written** — the + bundle is the mesh's own installer and nothing installs from it. A bed that raises a first node + is exactly that check, and it is the bed that cannot run. +- **A step naming what it needs.** The certificate step names an image and assumes a program inside + it. An action that said which tool it requires would have failed at the declaration rather than + at 127 on a machine. + +## Evidence to carry into diagnosis + +- `mesh-host examples/foundation-first-node.lock` — the previous broker, no `MESH_BUS_NATS`. +- `mesh-host examples/foundation-first-node-nats.lock` — the new bus; `bus-certificate` and its + `verify` both run `openssl` in the bus's image. +- The bus image the bundle pins has `sh` and no `openssl`; the store's image likewise. +- The lab rewrites a bundle's registry-prefixed third-party references to upstream ones for a + machine with an uplink (`test/integration/harness.ts`); the new bundle's bus reference needed + that rule added, which is done and is not this issue.