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.
57 lines
2.7 KiB
Markdown
57 lines
2.7 KiB
Markdown
---
|
|
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.
|
|
|
|
## 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.
|
|
|