70 lines
4.2 KiB
Markdown
70 lines
4.2 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-22
|
|
located-in: [mesh-controller cmd/mesh-controller/adoption.go (take previews nothing), mesh-host internal/apply (the comparison and the record)]
|
|
fixed-by: mesh-host 64 (genesis raises the forge as `gitea`, on the module's image digest, with the module's data directory at /data; a test holds the installer to the module's manifest)
|
|
amended-design:
|
|
---
|
|
|
|
# 090 — The forge module does not take over the forge genesis raised
|
|
|
|
## What was observed
|
|
|
|
Found in review of the fix for
|
|
[issue 085](../085-the-packages-port-given-at-genesis-is-not-a-setting/00-report.md), 2026-09-22.
|
|
|
|
Genesis raises a forge before any module exists, so the mesh has somewhere to keep its own
|
|
packages. The intention is that the forge's module later takes that running forge over, the way
|
|
the store and the broker are taken over in place
|
|
([ADR 0078](../../02-DECISIONS/0078-the-store-and-broker-are-modules.md)).
|
|
|
|
It cannot, as things stand. The forge genesis raises and the forge the module declares differ in
|
|
four ways at once:
|
|
|
|
- **the container's name** — the module's is not the one genesis used;
|
|
- **the network** — genesis runs it on the machine's own network, the module's runs bridged;
|
|
- **where its data lives** — genesis gives it no data volume of its own; the module mounts one;
|
|
- **the address it is told to call itself** — genesis sets it from the port given; the module
|
|
sets none;
|
|
- **the image itself.** Checked in the code on 2026-09-23: the two are pinned to **different
|
|
digests**, while the comment above the installer's constant says they are *pinned identically so
|
|
the module adopts the running server rather than replacing it*. A comment asserting a fact about
|
|
the system, and the fact is not true.
|
|
|
|
Assigning the module therefore does not adopt what is running. It raises a second forge, with a
|
|
different name, on a different network, with a different data directory, beside the first.
|
|
|
|
## Why it matters beyond this instance
|
|
|
|
Adoption in place is how the mesh is supposed to hand anything genesis raised to the module that
|
|
owns it afterwards. It works for the store and the broker because the container's name and its
|
|
data are the same on both sides. Nothing checks that a module which is meant to take over what
|
|
genesis raised actually can, and the check is not hard to state: same name, same data, same
|
|
network, or it is not a takeover.
|
|
|
|
## Open questions
|
|
|
|
- Should genesis raise the forge exactly as the module declares it — name, network and data
|
|
directory — so the module adopts it by the rule that already exists?
|
|
- Should something refuse to call a module the successor of a bootstrap service it cannot adopt?
|
|
- Is the forge's own address better resolved than set, which is [issue 088](../088-the-forges-own-address-names-a-port-it-may-not-have/00-report.md)?
|
|
|
|
## Decided, 2026-10-01
|
|
|
|
[ADR 0163](../../02-DECISIONS/0163-taking-a-module-over-is-a-comparison.md), rule 7: genesis raises as the module declares. Building follows,
|
|
host first, then the controller's `take`.
|
|
|
|
## Built in part, 2026-10-02
|
|
|
|
mesh-host 64: genesis raises the forge under the module's container name (`gitea`), pinned to the
|
|
module's image digest, with the module's data directory mounted at `/data` — so the module finds it,
|
|
holds it, and a take compares equal images and the same data. A test holds the installer's constants
|
|
to the module's manifest where the catalogue is checked out beside it. The network is the difference
|
|
left: the bootstrap forge runs on the machine's network to reach the store on its loopback, the module
|
|
runs bridged and publishes its ports, and the take says so. Closing waits for group 9's genesis test —
|
|
a mesh raised, the module assigned, and the module found holding rather than raising a second forge.
|
|
|
|
## Resolved, 2026-10-02
|
|
|
|
Closed on the operator's decision of 2026-10-02. Name, image and data directory align; the network does not — the bootstrap forge runs on the machine's network to reach the store on its loopback, the module runs bridged — and a take says so rather than hides it. Whether genesis should move the forge onto a bridge, and the test that raises a mesh and finds the module holding rather than raising a second forge, belong to group 9's genesis work and are not owed by this record any more.
|