ADR 0147: a module anchors the mesh's authority, and issue 146: the foundation cannot be raised #184

2026-09-29T13:28:19Z

jschoubben commented

2026-09-29 13:28:19 +00:00

Issue 129 answered, and a second issue found on the way to checking the answer.

ADR 0147 — every internal HTTPS name fails verification on every machine, because nothing has ever written the mesh's root into a trust store. The issue proposed the controller inject it, the way the private network writes the registry's trust (ADR 0082); this record rejects that. Being on the network is what makes the registry reachable, which is why presence is the right trigger there; trusting an authority is a different fact, and where a machine keeps its anchors is the host's difference, not the controller's. So: a module requiring internal-acme-ca fetches the root, installs it, refreshes the bundles — and being unassigned stops the unit, which takes it away again.

Issue 129 moves to located, owned by mesh-catalog ca-trust, with the trail in 01-diagnosis.md. 03-DESIGN/01-to-be/08-connectivity.md carries the paragraph.

Issue 146 — the bed this record names cannot run, and neither can any other. Raising a foundation fails before a module is reached: the older bundle raises the previous broker and a control plane that refuses to start without MESH_BUS_NATS; the newer one asks for a certificate from openssl in an image that has none. So 0147's "how this is checked" says plainly that what stands behind it today is the rendering, not a machine that verified anything.

Companion branches: mesh-catalog feat/ca-trust (the module), mesh-controller feat/ca-trust (the rendering test), mesh-lab feat/ca-trust (the bed).

Issue 129 answered, and a second issue found on the way to checking the answer. **ADR 0147** — every internal HTTPS name fails verification on every machine, because nothing has ever written the mesh's root into a trust store. The issue proposed the controller inject it, the way the private network writes the registry's trust (ADR 0082); this record rejects that. Being on the network is what makes the registry *reachable*, which is why presence is the right trigger there; trusting an authority is a different fact, and where a machine keeps its anchors is the host's difference, not the controller's. So: a module requiring `internal-acme-ca` fetches the root, installs it, refreshes the bundles — and being unassigned stops the unit, which takes it away again. Issue 129 moves to `located`, owned by `mesh-catalog ca-trust`, with the trail in `01-diagnosis.md`. `03-DESIGN/01-to-be/08-connectivity.md` carries the paragraph. **Issue 146** — the bed this record names cannot run, and neither can any other. Raising a foundation fails before a module is reached: the older bundle raises the previous broker and a control plane that refuses to start without `MESH_BUS_NATS`; the newer one asks for a certificate from `openssl` in an image that has none. So 0147's "how this is checked" says plainly that what stands behind it today is the rendering, not a machine that verified anything. Companion branches: `mesh-catalog feat/ca-trust` (the module), `mesh-controller feat/ca-trust` (the rendering test), `mesh-lab feat/ca-trust` (the bed).

jschoubben added 2 commits 2026-09-29 13:28:20 +00:00

ADR 0147: a module anchors the mesh's authority on a machine, and takes it away again 6c14d313b8

Issue 129: every internal HTTPS name fails verification on every machine,
because nothing has ever written the mesh's root into a trust store. The
report proposed the controller inject it the way the private network writes
the registry's trust; this record rejects that — reachability and trust are
not the same fact, and where anchors live is the host's difference, not the
controller's. A module requiring internal-acme-ca does the whole of it, and
being unassigned undoes it.

Issue 146: the foundation cannot be raised on the bus the mesh runs on 4a51ea4b3a

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.

jschoubben added 1 commit 2026-09-29 13:42:35 +00:00

Issue 146 diagnosed: four faults stacked, three fixed, the fourth is genesis bffd2af40c

Raising a first node hits them in order: the bundle's bus image named for a
registry that is gone; the certificate made by openssl in an image that has
none; enrolment dialling TLS at a bus that speaks first, then refusing its own
token for the empty bus. Each was right until the bus changed and nothing has
raised a foundation since.

The fourth is not a patch: the installer carries the bus's first user list and
the controller composes the rest through the bus being a module, and at genesis
there is no module — so the first node cannot be let onto the bus it just
raised.

jschoubben merged commit 0b08cdfce1 into main

2026-09-29 14:06:41 +00:00

jschoubben deleted branch decision/0147-a-module-anchors-the-meshs-authority

2026-09-29 14:06:41 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#184