51 lines
2.5 KiB
Markdown
51 lines
2.5 KiB
Markdown
---
|
|
status: open
|
|
opened: 2026-09-22
|
|
located-in: []
|
|
fixed-by:
|
|
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)?
|