jschoubben
0af6479b2c
Both repository checks fail on main. 0115 is cited by no design, and it is marked accepted while resting on 0112, which is proposed. Design 27 already states the rule the record decides — "a module is assigned at most once to a node, and that pair is the assignment's identity" — so it is the home, and now says so. And 0112, 0113, 0114 and design 27 are all proposed: the batch is under review, so the record is too. Promoting 0112 instead would be marking a record accepted to satisfy a check, which check_rests_on names as a failure this repository already made once.
50 lines
2.4 KiB
Markdown
50 lines
2.4 KiB
Markdown
---
|
|
topic: what runs on it
|
|
status: proposed
|
|
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.
|