Merge pull request '0115: one assignment of a module per node — the requirement is dropped' (#133) from decision/0115-one-assignment-per-module-per-node into main

2026-09-26 16:53:12 +00:00
parent dc80116b09 9516d31a62
commit 3950c2b75d
1 changed files with 49 additions and 0 deletions
@@ -0,0 +1,49 @@
 ---
 topic: what runs on it
 status: accepted
 date: 2026-09-26
 deciders: jochen
 extends: 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](../04-ISSUES/119-a-module-definition-decides-where-its-files-live/00-report.md)
 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.