jschoubben
4eb16f1028
0037 (where a module lives), 0113 (the vault makes every secret) and 0115 (one assignment of a module per node) described arrangements the mesh has — a catalogue of other people's software plus a table filled by module add, a vault answering a secret requirement six modules make, and a rule the assignment table's primary key already enforces. Each is accepted against what was built, and says so in its own words. 0037's other half is not built: a manifest outside this catalogue has no check, which is issue 148. 0068 (the lab takes requests) and 0114 (a shared credential rotates over two credentials) stay proposed. Neither is built, and both are decisions rather than records of something that happened.
2.7 KiB
topic, status, date, deciders, extends
| topic | status | date | deciders | extends |
|---|---|---|---|---|
| what runs on it | accepted | 2026-09-26 | jochen | 0112-a-module-definition-names-no-node-mesh-or-path.md |
115. One assignment of a module per node: the module's name is the assignment's identity
Context
Everything an assignment owns is named after its module: the database user
(mesh_<node>_<module>), the broker account (<node>-<module>), the containers, the sealed
secrets, and — since ADR 0112 — the placed directory (<root>/<module>). A second assignment
of the same module on the same node would collide on every one of those names at once, which
is why the mesh has never allowed it.
Issue 119 recorded this as a kept limitation, and 0112 deliberately did not fix it — giving assignments identities of their own would have touched every naming recipe in one already-large change. The question stayed open: is multi-assignment a requirement deferred, or a requirement at all?
The original motivation was real — one module serving two tenants on one machine, a second photo site, a second mail domain. The operator held that requirement once and has now weighed it against what it costs.
Decision
Dropped. One assignment of a module per node is the rule, not a limitation. The module's name IS the assignment's identity on a node, permanently, and every naming recipe may rely on it.
Wanting the same software twice on one node has a spelling the mesh already supports: two modules. A module definition is cheap — two photo sites are two modules sharing artifacts (the build's images are content-addressed; nothing is built twice), each with its own name, its own directory, its own grants and its own routes. The tenant boundary lands where every other boundary already is: the module name.
Consequences
- The naming recipes stay as simple as they are. No instance suffixes, no assignment ids threaded through six systems, no migration of every existing name.
<root>/<module>is the assignment's directory with nothing left open (0112's placement language stands unchanged).- The controller may refuse a second assignment plainly — "novox already runs mailu, and one node runs one of each (ADR 0115)" — instead of failing on whichever name collides first.
- Multi-tenant asks are answered in the catalogue (a second module definition), not in the control plane.
Accepted, 2026-09-29, against what was built
Marked in a grooming pass. The rule is enforced where it cannot be forgotten: assignment's
primary key is (node, module), so a second assignment of one module to one machine is not a thing
the mesh can hold. The record read proposed while the schema had already settled it.