Compare commits
397
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
8184585213 | ||
|
|
d7bb24b181 | ||
|
|
23d6e30b8a | ||
|
|
2043e90f35 | ||
|
|
c9418af42e | ||
|
|
9c3e77999e | ||
|
|
6943843fff | ||
|
|
34325d3566 | ||
|
|
fa9e94d863 | ||
|
|
1b34821aa0 | ||
|
|
50ddaf8408 | ||
|
|
f5d518d256 | ||
|
|
577ddf0089 | ||
|
|
13e28e6873 | ||
|
|
6b6ff76a19 | ||
|
|
8d5e6ef76f | ||
|
|
77813f4613 | ||
|
|
4ee8e3905d | ||
|
|
216faec69e | ||
|
|
e36b1a9e9c | ||
|
|
5886969c75 | ||
|
|
5fa43ff755 | ||
|
|
1de4a5f25e | ||
|
|
8a1fa37dce | ||
|
|
44eb13acd0 | ||
|
|
6d53f9168a | ||
|
|
6a1fc71a4c | ||
|
|
fb76fb7256 | ||
|
|
2344bfb69b | ||
|
|
ca8a865e73 | ||
|
|
27c6881287 | ||
|
|
f8458d6f2c | ||
|
|
c5778f4366 | ||
|
|
4c1ad0ed45 | ||
|
|
9873e951a9 | ||
|
|
e5e6e56ecf | ||
|
|
65c30c576a | ||
|
|
ee17cddb74 | ||
|
|
22e96e5bc7 | ||
|
|
7e464e3b22 | ||
|
|
502763ce5e | ||
|
|
eaae0e2b80 | ||
|
|
2ee6eab7b9 | ||
|
|
ce5f85f65e | ||
|
|
911125148c | ||
|
|
d718a917e5 | ||
|
|
a572868333 | ||
|
|
55443b67e6 | ||
|
|
89a202f12e | ||
|
|
b342c9c3da | ||
|
|
336b8c9b62 | ||
|
|
0c82909845 | ||
|
|
d8a0c1b02f | ||
|
|
b232b44f4c | ||
|
|
c03f2cd4c6 | ||
|
|
73c4d24024 | ||
|
|
3372d72da0 | ||
|
|
273b932329 | ||
|
|
f91a3efb6b | ||
|
|
2f0ce4ce19 | ||
|
|
bf3338898e | ||
|
|
4891cdeac5 | ||
|
|
733cff4c3c | ||
|
|
561f26fb34 | ||
|
|
d8a58dadcf | ||
|
|
3f4782cfb4 | ||
|
|
d076647b5d | ||
|
|
ae83c5e09b | ||
|
|
feeea127e2 | ||
|
|
76b563e0ce | ||
|
|
f56686d1e5 | ||
|
|
5938d40dee | ||
|
|
f062672f83 | ||
|
|
e4a0c73e2b | ||
|
|
d1aeee42a4 | ||
|
|
81d780f973 | ||
|
|
3e30846e0f | ||
|
|
b3f18c54c6 | ||
|
|
e11bf320c9 | ||
|
|
da8b4b4ee4 | ||
|
|
c026d5221e | ||
|
|
983fd412c6 | ||
|
|
9ac2493e2c | ||
|
|
560f25c2c7 | ||
|
|
9e0288128b | ||
|
|
709240ec1f | ||
|
|
d57289e049 | ||
|
|
d4a2f99ab5 | ||
|
|
a9f91fdd0c | ||
|
|
131a5e4714 | ||
|
|
329a24fdae | ||
|
|
7f72f3b79a | ||
|
|
114a71f36f | ||
|
|
0f407417f3 | ||
|
|
4af731df19 | ||
|
|
7b1dabbce0 | ||
|
|
2caa5e827b | ||
|
|
179fd7f83f | ||
|
|
d0d5799884 | ||
|
|
9ba4de5557 | ||
|
|
e1203e5a43 | ||
|
|
4ce967619a | ||
|
|
6df2cfecd6 | ||
|
|
73047501f6 | ||
|
|
bf39baf104 | ||
|
|
5eadf36937 | ||
|
|
8c9a2c7501 | ||
|
|
54213ba90c | ||
|
|
7fb59bde98 | ||
|
|
a4d24d7b65 | ||
|
|
116b2d1793 | ||
|
|
68a14493c9 | ||
|
|
98eb3aa76f | ||
|
|
91bbe648a8 | ||
|
|
0e7b85f184 | ||
|
|
dac49de6e7 | ||
|
|
0d9208dbbf | ||
|
|
bf0ee7cb25 | ||
|
|
4567e13071 | ||
|
|
aa5d9f1045 | ||
|
|
79642251a1 | ||
|
|
331cb94c6e | ||
|
|
17ca9a262b | ||
|
|
967c793eaa | ||
|
|
78351560f7 | ||
|
|
62cc2f89c7 | ||
|
|
426f741ad0 | ||
|
|
9bed54d3be | ||
|
|
413daf8ad5 | ||
|
|
5c993c09b7 | ||
|
|
7c3be48db2 | ||
|
|
b665d06701 | ||
|
|
1bd13446d4 | ||
|
|
14adaafa53 | ||
|
|
bd673cc6ec | ||
|
|
bd6c55d225 | ||
|
|
2bbbc56502 | ||
|
|
c8935aceca | ||
|
|
29b656f2c0 | ||
|
|
d05ac367f1 | ||
|
|
1c0dafb918 | ||
|
|
018ee359ae | ||
|
|
c5535eeebd | ||
|
|
dbb9d2bc16 | ||
|
|
28d53dcc28 | ||
|
|
df667eb710 | ||
|
|
098a2ca485 | ||
|
|
a34cedeb5d | ||
|
|
db5ff5a5ee | ||
|
|
780c2b6e58 | ||
|
|
27c1db8a86 | ||
|
|
24aeb203f7 | ||
|
|
afbfd5f29d | ||
|
|
696957aa5e | ||
|
|
3d54fcbb86 | ||
|
|
b13ef1be81 | ||
|
|
c4151e6bc4 | ||
|
|
8c231102f8 | ||
|
|
f1941304cc | ||
|
|
d8083bcf9e | ||
|
|
6f26f97fdb | ||
|
|
63ed4a7c96 | ||
|
|
48ca2fb41b | ||
|
|
3976f09738 | ||
|
|
2904c359b8 | ||
|
|
b277f3b4ba | ||
|
|
50e4d9c2a7 | ||
|
|
a7d0dd83d1 | ||
|
|
a2c9fbb665 | ||
|
|
0278766dfb | ||
|
|
606fbb7add | ||
|
|
a92e4bf121 | ||
|
|
187442ec7b | ||
|
|
47c45d4386 | ||
|
|
82496536cd | ||
|
|
b0de267301 | ||
|
|
b0a74b23fd | ||
|
|
6a5f68d11f | ||
|
|
821cd3b489 | ||
|
|
49b0319230 | ||
|
|
86d1763cfa | ||
|
|
a7e9e6dea0 | ||
|
|
ea0853ca46 | ||
|
|
fcd27c8399 | ||
|
|
03e39316ea | ||
|
|
65a252dc00 | ||
|
|
6be284c781 | ||
|
|
ea9a433385 | ||
|
|
9ddd7215ad | ||
|
|
626af3e8e2 | ||
|
|
180e3b8f7e | ||
|
|
4ae452d0ad | ||
|
|
f35f3757bb | ||
|
|
6b8fb562ce | ||
|
|
2175d13935 | ||
|
|
39f0d64840 | ||
|
|
eef03f2b08 | ||
|
|
64acc94de8 | ||
|
|
99eb322de5 | ||
|
|
5460681117 | ||
|
|
0acb47fa55 | ||
|
|
7a633f2780 | ||
|
|
bef510fda2 | ||
|
|
c58f4d6790 | ||
|
|
d29d3dfc23 | ||
|
|
d85b41ae4d | ||
|
|
e00e3bc3ce | ||
|
|
b8d8101c45 | ||
|
|
85961f8348 | ||
|
|
48a620249b | ||
|
|
7f0fe27cf2 | ||
|
|
bfc410fafe | ||
|
|
d436122be2 | ||
|
|
76a535e69e | ||
|
|
027e5b8d73 | ||
|
|
79d1619f16 | ||
|
|
5a6b7ca4f8 | ||
|
|
e1f2c6bd5b | ||
|
|
cf8134e318 | ||
|
|
35f7f4401b | ||
|
|
62d61938ad | ||
|
|
f841845b0d | ||
|
|
3627f7e9db | ||
|
|
2ffe1d0915 | ||
|
|
763e327610 | ||
|
|
93f828c5eb | ||
|
|
fe706af63a | ||
|
|
52e9df0f02 | ||
|
|
36454d7e4a | ||
|
|
e84c822e89 | ||
|
|
a170913202 | ||
|
|
9a20c16d9b | ||
|
|
8bd0ca0bdc | ||
|
|
598f6a8952 | ||
|
|
3341c037cb | ||
|
|
22a28ad548 | ||
|
|
1e1957a9c4 | ||
|
|
5292f4176a | ||
|
|
822e8b03f8 | ||
|
|
a82941ee0c | ||
|
|
9ffb7eec55 | ||
|
|
7499f1e50c | ||
|
|
214b486a50 | ||
|
|
90b44a48df | ||
|
|
860331dc37 | ||
|
|
37b46d5349 | ||
|
|
16855ade02 | ||
|
|
8dd566c0aa | ||
|
|
a98ee0f529 | ||
|
|
ad4a5ea004 | ||
|
|
0cf1ad5dad | ||
|
|
69a002fce3 | ||
|
|
16a1a52cd8 | ||
|
|
af170e3a67 | ||
|
|
6c2d5f5913 | ||
|
|
04c9500b5b | ||
|
|
d0044cf555 | ||
|
|
846c1f85f2 | ||
|
|
9eef0bd525 | ||
|
|
105ae9a56a | ||
|
|
ee801a6441 | ||
|
|
90b89aa1c9 | ||
|
|
e33191161d | ||
|
|
6e08cdf3d6 | ||
|
|
02f291a129 | ||
|
|
a0a930b1cd | ||
|
|
8d9c9ab6b5 | ||
|
|
9b14430d3f | ||
|
|
a4384f13d3 | ||
|
|
49b1136ded | ||
|
|
743051efe7 | ||
|
|
e8470057aa | ||
|
|
a841e2c173 | ||
|
|
3c535ead31 | ||
|
|
4cf941d858 | ||
|
|
5042ffd8d3 | ||
|
|
39340fcd76 | ||
|
|
4f9dc3906e | ||
|
|
a2542e51f8 | ||
|
|
b19b29cd3a | ||
|
|
4bf4fe2d06 | ||
|
|
5e12081774 | ||
|
|
9ad64881a9 | ||
|
|
266ade6e28 | ||
|
|
a794ef9a3f | ||
|
|
e10084fed6 | ||
|
|
941b920bd7 | ||
|
|
ecbd2ce2e6 | ||
|
|
b7f7b97d8a | ||
|
|
c2cf0d72d6 | ||
|
|
0a5006b366 | ||
|
|
3ea9601904 | ||
|
|
f7a37ee4f3 | ||
|
|
601d004fcb | ||
|
|
d009c3efef | ||
|
|
5036b927b9 | ||
|
|
1f72e82b84 | ||
|
|
76fbe323ea | ||
|
|
295bf2f3ab | ||
|
|
e1b74810a8 | ||
|
|
e41eed0852 | ||
|
|
ba30286896 | ||
|
|
53b94c51bb | ||
|
|
83791f0921 | ||
|
|
bf4d4e2e7b | ||
|
|
ec42ee0846 | ||
|
|
5a3dee9e9e | ||
|
|
47909c6b71 | ||
|
|
7e5edab8da | ||
|
|
3649f82204 | ||
|
|
b400ce2c54 | ||
|
|
995c8cb266 | ||
|
|
f89aef992d | ||
|
|
b967ef7be3 | ||
|
|
e417906241 | ||
|
|
b1bf895688 | ||
|
|
0d64677c70 | ||
|
|
04205c1dc8 | ||
|
|
9dc49cd831 | ||
|
|
66b413a076 | ||
|
|
fcba05fed9 | ||
|
|
18f37c25b2 | ||
|
|
3c2b4fc6b6 | ||
|
|
72eaf52867 | ||
|
|
741625e725 | ||
|
|
c3730b9a23 | ||
|
|
3a59099c81 | ||
|
|
3bd6f34de3 | ||
|
|
2b5119ecd2 | ||
|
|
96bdffa9bc | ||
|
|
4eb16f1028 | ||
|
|
d199de40db | ||
|
|
9a1dc4665c | ||
|
|
14be8576f8 | ||
|
|
ec8676c225 | ||
|
|
3c0f7082e6 | ||
|
|
0dd00e88b6 | ||
|
|
eef54917ec | ||
|
|
e9b1010bc0 | ||
|
|
f6ed3545b7 | ||
|
|
0b08cdfce1 | ||
|
|
bffd2af40c | ||
|
|
4a51ea4b3a | ||
|
|
6c14d313b8 | ||
|
|
ced547dae9 | ||
|
|
38482435af | ||
|
|
cf8a8d78c9 | ||
|
|
9de25994e9 | ||
|
|
64ea47b11d | ||
|
|
eba24a72af | ||
|
|
78d4873f4f | ||
|
|
ddfd62edf6 | ||
|
|
f65664640a | ||
|
|
492ac7be18 | ||
|
|
5ac77e3cef | ||
|
|
a619022c35 | ||
|
|
49c065c204 | ||
|
|
ddb3980f09 | ||
|
|
75a8f6abc7 | ||
|
|
862253518f | ||
|
|
51ef3eb7e2 | ||
|
|
346e613995 | ||
|
|
25ca9898d5 | ||
|
|
709c095387 | ||
|
|
c262de3833 | ||
|
|
a815433214 | ||
|
|
61dc90e508 | ||
|
|
a7cf5c0c1b | ||
|
|
c6f86ae935 | ||
|
|
1aeb4fe8d8 | ||
|
|
08108b569d | ||
|
|
14ff89fa40 | ||
|
|
2126e7b2cb | ||
|
|
dcdfcf104e | ||
|
|
d23ace1646 | ||
|
|
5dbde0b13a | ||
|
|
db3868e2b0 | ||
|
|
05039c4f10 | ||
|
|
b7bf601ca4 | ||
|
|
bff32e3370 | ||
|
|
d6b62387f2 | ||
|
|
4789624857 | ||
|
|
e00862e317 | ||
|
|
3a92e4b80c | ||
|
|
bfddf78bf3 | ||
|
|
0b291d89f3 | ||
|
|
a924efcc28 | ||
|
|
b421c73a5a | ||
|
|
017b1401e4 | ||
|
|
476cda417d | ||
|
|
74ba3ff1d4 | ||
|
|
891c7a945e | ||
|
|
83cbeb8db8 | ||
|
|
ab6db9369b | ||
|
|
84571b4825 | ||
|
|
e6402cf777 | ||
|
|
4f0d144833 |
@@ -54,4 +54,6 @@ whose failure has never been observed is a guess about its own correctness.
|
||||
The development cycle, checked ([ADR 0080](../../02-DECISIONS/0080-the-development-cycle-is-checked.md)):
|
||||
a to-be design names a decision, an in-progress/implemented design names its owning code, a
|
||||
located/fixed issue names its owner, a fixed/resolved issue says what fixed it, a graduated
|
||||
research overview says what it became. `python3 00-META/checks/cycle.py`
|
||||
research overview says what it became, and no two issue records share a number (issue 155 — the
|
||||
number is how a record is cited, and `main` lags every open pull request, so two people reading it
|
||||
allocate the same one). `python3 00-META/checks/cycle.py`
|
||||
|
||||
+39
-1
@@ -14,7 +14,8 @@ What is enforced:
|
||||
its owning code (`code:`) -- no development without a design that says where.
|
||||
issues a known `status:`; once `located`, `located-in:` names the owner;
|
||||
once `resolved`, `fixed-by:` says what fixed it (prose counts --
|
||||
"nothing, the capability existed" is an answer).
|
||||
"nothing, the capability existed" is an answer). And no two records share a
|
||||
number -- the number is how a record is cited.
|
||||
research a known `status:`; a `graduated` overview says what it `became:`, and every
|
||||
target it names exists.
|
||||
decisions every accepted record is REACHABLE from the cycle: cited by a design doc's
|
||||
@@ -109,6 +110,43 @@ def main():
|
||||
"without a design that says where" % status)
|
||||
|
||||
# ---- issues ------------------------------------------------------------------------
|
||||
# Two records may not share a number. Numbers are taken as "next free after main", and work
|
||||
# sits on unmerged branches for days -- so two people reading the same main allocate the same
|
||||
# number, and nothing said so. It happened twice in one evening between two machines, and the
|
||||
# second collision landed on main with all three checks passing (issue 155). An issue number is
|
||||
# how every other record cites this one; two records answering to it means a pointer that
|
||||
# resolves to whichever the reader happened to open.
|
||||
seen = {}
|
||||
for folder in sorted(glob.glob(os.path.join(ROOT, "04-ISSUES", "*", ""))):
|
||||
name = os.path.basename(os.path.normpath(folder))
|
||||
number = name.split("-", 1)[0]
|
||||
if not number.isdigit():
|
||||
continue
|
||||
if number in seen:
|
||||
bad(os.path.join("04-ISSUES", name),
|
||||
"is numbered %s, and so is %s -- an issue number is how it is cited, and two "
|
||||
"records answering to one means a citation that resolves to whichever the reader "
|
||||
"opened. Take the next free number across main AND every open pull request"
|
||||
% (number, seen[number]))
|
||||
else:
|
||||
seen[number] = name
|
||||
|
||||
# And decision records, which 155's fix left out: on 2026-10-02 two ADRs numbered 0169 landed
|
||||
# on main from two sessions within the hour, and every check passed.
|
||||
seen_records = {}
|
||||
for path in sorted(glob.glob(os.path.join(ROOT, "02-DECISIONS", "[0-9]*.md"))):
|
||||
name = os.path.basename(path)
|
||||
number = name.split("-", 1)[0]
|
||||
if not number.isdigit():
|
||||
continue
|
||||
if number in seen_records:
|
||||
bad(os.path.join("02-DECISIONS", name),
|
||||
"is numbered %s, and so is %s -- a record's number is how it is cited. Take the next "
|
||||
"free number across main AND every open pull request; the branch that lands last "
|
||||
"renumbers" % (number, seen_records[number]))
|
||||
else:
|
||||
seen_records[number] = name
|
||||
|
||||
for path in sorted(glob.glob(os.path.join(ROOT, "04-ISSUES", "*", "00-report.md"))):
|
||||
front = frontmatter(path)
|
||||
if front is None:
|
||||
|
||||
@@ -164,6 +164,12 @@ def check_rests_on(failures, records):
|
||||
# decision is exactly what as-is is for."
|
||||
if rel(path).startswith("03-DESIGN/00-as-is/"):
|
||||
continue
|
||||
# A withdrawn record's citations are history. It instructs nobody -- every reader
|
||||
# is sent to its superseder -- so what it was built on may itself be withdrawn.
|
||||
# Refusing that would mean rewriting the lineage of a record whose reasoning is
|
||||
# the thing the immutability rule protects.
|
||||
if frontmatter(read(path)).get("status") == "superseded":
|
||||
continue
|
||||
# An extension that supersedes legitimately names what it replaced.
|
||||
this = ADR_FILE.match(os.path.basename(path))
|
||||
supersedes = records[number]["front"].get("superseded-by", "")
|
||||
@@ -241,13 +247,20 @@ def check_supersession_symmetry(failures, records):
|
||||
failures.add("supersession", rel(record["path"]), f"superseder does not exist: {by}")
|
||||
continue
|
||||
other = records[match.group(1)]
|
||||
claims = os.path.basename(str(other["front"].get("supersedes", "")))
|
||||
if claims != record["name"]:
|
||||
# `supersedes:` may name one record or several. One decision replacing two is a real
|
||||
# situation -- two records that built and refined the same wrong mechanism are withdrawn
|
||||
# by the one record that removes it -- and a check that allows only one would force
|
||||
# either a chain of pro-forma records or an unmarked supersession.
|
||||
claimed = other["front"].get("supersedes", "")
|
||||
if isinstance(claimed, str):
|
||||
claimed = [claimed] if claimed else []
|
||||
claims = [os.path.basename(str(entry)) for entry in claimed]
|
||||
if record["name"] not in claims:
|
||||
failures.add(
|
||||
"supersession",
|
||||
rel(other["path"]),
|
||||
f"ADR {number} says this supersedes it; this record does not say so "
|
||||
f"(supersedes: {claims or 'absent'})",
|
||||
f"(supersedes: {', '.join(claims) or 'absent'})",
|
||||
)
|
||||
|
||||
|
||||
|
||||
+40
-2
@@ -9,6 +9,11 @@ another — and a mesh you cannot name precisely is a mesh two people describe d
|
||||
|
||||
- **node** — a machine in the mesh. There are 0..n of them, and each runs the host agent. A node is
|
||||
just a machine that has joined; being one implies nothing about what it runs.
|
||||
- **operator account** — the login name of the person who works on a node, stated on the node
|
||||
record; empty for a machine nobody logs into. Everything the mesh places under a person's home is
|
||||
resolved against this account's home and owned by it
|
||||
([ADR 0181](../02-DECISIONS/0181-the-operator-account-is-a-node-fact-and-a-home-is-a-placement-root.md)).
|
||||
Not "the user" (ambiguous with a module's own account) and not a name a definition carries.
|
||||
- **control-node** — the one node that also holds the `mesh-controller` seat. There is exactly one
|
||||
per mesh. "control-node" is not a separate kind of machine — it is a node that additionally runs
|
||||
the controller (and, today, the foundation). Lose it and the other nodes keep running what they
|
||||
@@ -52,8 +57,11 @@ another — and a mesh you cannot name precisely is a mesh two people describe d
|
||||
|
||||
- **package** — what code resolves when it is **compiled**: an npm/cargo/pypi dependency, by
|
||||
**version**. Served by the **package-registry** (gitea). Only a builder talks to it.
|
||||
- **artifact** — what the mesh delivers to a machine to **install and run**: an OCI image, by
|
||||
**digest**. Served by the **artifact-store** (distribution). Every node pulls from it.
|
||||
- **artifact** — anything a build produces and the mesh delivers to a machine by **digest**: an
|
||||
`image`, a mirrored `upstream` image, a `bundle` of the module's own code, an `archive`. Served by
|
||||
the **artifact-store**, an OCI registry that holds every kind as content-addressed blobs
|
||||
([ADR 0156](../02-DECISIONS/0156-an-artifact-is-what-a-build-produces-and-the-store-is-named-for-its-scope.md)).
|
||||
Every node pulls from it. An image is one kind of artifact, and a module is not an image.
|
||||
- These are two protocols, not one store being weak — see [ADR 0075](../02-DECISIONS/0075-two-stores-and-which-provides-what.md).
|
||||
|
||||
## How modules relate to the mesh
|
||||
@@ -75,8 +83,38 @@ another — and a mesh you cannot name precisely is a mesh two people describe d
|
||||
is a role you occupy, and the two meet where a seat delivers a provision: occupying the seat is
|
||||
what makes a module *the* provider of it.
|
||||
|
||||
## The surfaces
|
||||
|
||||
- **console** — the module (`mesh-console`) that puts the mesh's tools in front of whoever is on a
|
||||
machine: an MCP endpoint on the machine's loopback for an agent, the same endpoint for a person. It
|
||||
is assigned like any module, holds a credential the mesh minted, and calls tools under a grant its
|
||||
manifest declares (`invokes`). Loopback is the authority boundary: whoever is on the machine owns the
|
||||
mesh there ([ADR 0152](../02-DECISIONS/0152-the-operators-surface-is-a-module-the-console.md)).
|
||||
Not "the tool bridge", "the brain" or "the MCP server" — those name the predecessor's program or a
|
||||
protocol, and the console is a module.
|
||||
- **invokes** — the manifest word for the tools a module calls, `<module>.<tool>` each or `*` for
|
||||
every one. A grant on the publish side and nothing else; a module that declares none calls nothing.
|
||||
|
||||
## How this page is kept
|
||||
|
||||
A new name for an existing thing lands here first, in the same change that introduces it in code. A
|
||||
record under `02-DECISIONS/` keeps whatever word it was written with — those are immutable — so a
|
||||
term retired here may still appear there, and the mapping above is how to read it.
|
||||
|
||||
## The operator's machine
|
||||
|
||||
- **node tools** — the one tool runtime per node, a host-side process the host supervises, that loads
|
||||
every assigned module's tools bundle and serves every tool and held seat's verb on the subjects the
|
||||
memberships issue; its serving mode on loopback is what was called **the console**
|
||||
([ADR 0175](../02-DECISIONS/0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md)).
|
||||
Replaces **"console"** as the module's name; *console* remains the word for the person's end of it.
|
||||
- **bundle** — the artifact a module's own code is built into — its tools, a seat's implementation, a daemon — in any language the mesh has a toolchain for, interpreted or compiled; never an image. One module may declare several ([ADR 0188](../02-DECISIONS/0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)).
|
||||
- **kept region** — a marked block in a managed file the mesh writes *into*, where the operator's own
|
||||
lines survive every push and are given back when the module goes
|
||||
([ADR 0174](../02-DECISIONS/0174-a-node-varies-a-module-through-settings-and-kept-regions-never-an-edit.md)).
|
||||
One of the two ways a node varies a module; the other is a **setting**.
|
||||
- **installed / holding** — a module may be assigned (its package installed, its files placed) without
|
||||
holding the seat its family declares; *holding* is being the one — the login shell, the display
|
||||
session — on that node ([ADR 0176](../02-DECISIONS/0176-the-login-shell-is-a-node-seat-and-execute-is-its-contract.md)).
|
||||
- ~~flavor~~ — not used. What a flavor varied is a setting or a separate module.
|
||||
|
||||
|
||||
@@ -21,7 +21,12 @@ incident someone must **clear**.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Take the next free number. Create `04-ISSUES/NNN-short-name/00-report.md`:
|
||||
1. Take the next free number — **across `main` and every open pull request**, not `main` alone.
|
||||
Work sits on unmerged branches for days, so two people both reading `main` allocate the same
|
||||
number; it happened twice in one hour between two machines, and the second collision reached
|
||||
`main` with every check passing (issue 155). `cycle.py` now refuses two records sharing a number,
|
||||
which catches a collision but does not prevent one. Create
|
||||
`04-ISSUES/NNN-short-name/00-report.md`:
|
||||
|
||||
```yaml
|
||||
---
|
||||
@@ -42,6 +47,14 @@ incident someone must **clear**.
|
||||
## Rules
|
||||
|
||||
- Closed issues are never deleted — they are the mesh's symptom-to-component memory.
|
||||
- `fixed-by:` names something that will still exist: a commit or a pull request, never a branch. A
|
||||
branch is deleted when it merges, so a branch name there is a pointer that resolves to nothing by
|
||||
the time anybody follows it.
|
||||
- A fix that turns out to have broken something else is written back into the record that asked for
|
||||
it, pointing at the new issue. Somebody arriving at a record to learn why the code is the way it
|
||||
is must not have to already know there was a sequel.
|
||||
- Renumbering a collision happens once, in the branch that lands last. Renumbering a branch whose
|
||||
author is still pushing only moves the race.
|
||||
- An issue whose answer is a general lesson should also be written to the knowledge base, so
|
||||
the next person searching a symptom finds it. Both, not either.
|
||||
- `status: wontfix` is legitimate and requires a sentence saying why.
|
||||
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
status: graduated
|
||||
initiated: 2026-10-02
|
||||
touches:
|
||||
- 02-DECISIONS/0040-what-a-module-is.md
|
||||
- 02-DECISIONS/0011-managed-files-are-generated-never-edited.md
|
||||
- 02-DECISIONS/0132-a-seat-carries-the-tools-its-holder-must-serve.md
|
||||
- 02-DECISIONS/0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md
|
||||
- 02-DECISIONS/0152-the-operators-surface-is-a-module-the-console.md
|
||||
- 02-DECISIONS/0161-what-deserves-a-seat.md
|
||||
- 03-DESIGN/01-to-be/05-the-node-host.md
|
||||
- 03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md
|
||||
- 03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md
|
||||
- 03-DESIGN/01-to-be/34-the-console.md
|
||||
- 03-DESIGN/00-as-is/10-module-catalogue.md
|
||||
- 04-ISSUES/160-a-machine-says-little-about-itself-and-only-when-asked/00-report.md
|
||||
- 04-ISSUES/168-a-setting-reaches-every-file-and-contribution/00-report.md
|
||||
became:
|
||||
- 03-DESIGN/01-to-be/37-the-operators-machine.md
|
||||
- 02-DECISIONS/0173-the-operators-machine-is-the-meshs-and-a-module-is-what-it-declares.md
|
||||
- 02-DECISIONS/0174-a-node-varies-a-module-through-settings-and-kept-regions-never-an-edit.md
|
||||
- 02-DECISIONS/0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md
|
||||
- 02-DECISIONS/0176-the-login-shell-is-a-node-seat-and-execute-is-its-contract.md
|
||||
- 02-DECISIONS/0177-a-unit-may-be-user-scoped-and-the-service-manager-is-a-node-seat.md
|
||||
---
|
||||
|
||||
# 018 — The operator's machine as modules
|
||||
|
||||
**What.** The mesh owns the whole machine, not only the services on it. Everything a person
|
||||
configures on a node — the login manager, the display server, the window manager, the shell, the
|
||||
terminal, the launcher, the notifier, the audio setup, the boot images, the downloads folder, the
|
||||
agent at the terminal — is a module: a package, the files it owns under `/etc` and under the
|
||||
operator's home, the seat it holds, the tools it serves. One default configuration per module,
|
||||
varied per node only through settings rendered into the file or a kept operator region, never
|
||||
through an edit. The servers take the universal modules (shell, prompt, git, the agent); the
|
||||
workstations take those and the graphical stack, which a capability the machine reports gates.
|
||||
This effort writes that behaviour down, measures what the predecessor's desktop modules actually
|
||||
contain, and settles what the mesh must gain before the first of them can be written.
|
||||
|
||||
**Why.** The predecessor is retired on every node. What it still owned on the two workstations —
|
||||
about thirty modules' worth of dotfiles, user units and `/etc` files — is now owned by nothing:
|
||||
no generator regenerates them, and a fix to one of them is a hand edit that nothing records. The
|
||||
migration scoped these modules out as *the workstation's own environment*, and
|
||||
[to-be 29](../../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) names them as the last
|
||||
thing the predecessor was keeping alive. To-be 29 covers one directory, `~/.ssh`, and draws a
|
||||
boundary inside it. The operator wants no boundary: the machine is the mesh's, as far as it makes
|
||||
sense to configure it. That is a wider scope than any design states, and it reaches three records
|
||||
that were written for services: what a module is, where a module's tools run, and what a managed
|
||||
file may be.
|
||||
|
||||
**What it touches.** The module definition ([ADR 0040](../../02-DECISIONS/0040-what-a-module-is.md)),
|
||||
seats and their contracts ([ADR 0132](../../02-DECISIONS/0132-a-seat-carries-the-tools-its-holder-must-serve.md)),
|
||||
where a module's tools run ([ADR 0150](../../02-DECISIONS/0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md),
|
||||
[ADR 0152](../../02-DECISIONS/0152-the-operators-surface-is-a-module-the-console.md),
|
||||
[to-be 33](../../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md) §6), the host's vocabulary
|
||||
([to-be 05](../../03-DESIGN/01-to-be/05-the-node-host.md)), managed files and settings
|
||||
([ADR 0011](../../02-DECISIONS/0011-managed-files-are-generated-never-edited.md),
|
||||
[issue 168](../../04-ISSUES/168-a-setting-reaches-every-file-and-contribution/00-report.md)),
|
||||
and the catalogue's shape ([as-is 10](../../03-DESIGN/00-as-is/10-module-catalogue.md)).
|
||||
|
||||
**Documents.**
|
||||
|
||||
- [01 — The intended behaviour](01-the-intended-behaviour.md): the operator's wish, written as
|
||||
how the mesh behaves, in the mesh's own words.
|
||||
- [02 — What exists, and what is missing](02-what-exists-and-what-is-missing.md): the
|
||||
predecessor's desktop modules measured; which records already say what is wanted; the gaps.
|
||||
- [03 — One tool executor per node](03-one-tool-executor-per-node.md): where a module's tools
|
||||
run. The direction the operator set, the evidence for it, and what it supersedes.
|
||||
- [04 — The seats of the environment](04-the-seats-of-the-environment.md): the roles a machine
|
||||
has once, their candidate contracts, and what gates each.
|
||||
|
||||
**What it had to settle, and where each landed.** *(Graduated 2026-10-02.)*
|
||||
|
||||
1. A module is one *managed thing*, software or not, and every module may serve tools — or ADR
|
||||
0040 already says this and only its examples are narrow.
|
||||
2. One tool executor per node, host-side, module-agnostic; which records it supersedes and
|
||||
in what form the console continues.
|
||||
3. Per-node variation is a setting rendered into the file or a kept region, never an edit —
|
||||
ADR 0011 stands — and issue 168 is fixed before any environment module carries a setting.
|
||||
4. User-scoped units on the host's `service` shape, and a service-manager seat whose holder
|
||||
serves the tools about them.
|
||||
5. The operator account stated on every node; today no node record carries one.
|
||||
6. The seats of the environment and their verbs, one record per seat, slowly, because a
|
||||
seat's tools bind every future holder.
|
||||
7. Where the environment modules live: this catalogue, or one of their own as the media chain
|
||||
has; and whether a third-party organisation's tooling belongs in a public catalogue at all.
|
||||
@@ -0,0 +1,99 @@
|
||||
# 01 — The intended behaviour
|
||||
|
||||
*Written 2026-10-02 from the operator's words, in the mesh's words. What is wanted, before what
|
||||
exists. Where a sentence restates a record, the record is named; where it goes further, that is
|
||||
said.*
|
||||
|
||||
## The machine is the mesh's
|
||||
|
||||
**Everything configurable on a node is declared by a module.** Not only the services the mesh
|
||||
runs: the login manager, the display server, the window manager, the bar, the launcher, the
|
||||
notifier, the compositor, the lock screen, the terminal emulator, the clipboard, the shell and its
|
||||
prompt, the editor, the audio setup, the boot images, the package manager's configuration, the
|
||||
agent a person runs at a terminal, and the folders a person works in — a downloads folder that is
|
||||
tidied, backed up, distributed to other nodes and asked questions of. System folders and the
|
||||
operator's home alike. The operator is the only person on every node, so the mesh manages the
|
||||
person's machine, not a machine with a person on it.
|
||||
|
||||
This is [ADR 0040](../../02-DECISIONS/0040-what-a-module-is.md)'s definition applied without
|
||||
the service bias its examples carry. A module is one managed thing, named once, described
|
||||
completely by its manifest. It may have a package, files, a container, a unit, a binary, a seat it
|
||||
holds, and tools it serves — any one of these, or all, or two. There is **no kind of module**: zsh
|
||||
has a package, files, a seat claim and the tools that claim obliges it to serve; downloads has a
|
||||
folder, a process and tools; nftables has a package, files, a service, a seat and tools. The
|
||||
difference is what each declares, not what each is.
|
||||
|
||||
**The home has no boundary.** [To-be 29](../../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md)
|
||||
owns one directory under the home and draws a line inside it between the mesh's and the person's.
|
||||
Here the line is drawn only by what the modules declare: every file some module places is the
|
||||
mesh's; what no module declares is found and left alone, exactly as the adoption rules already
|
||||
say for a machine. The reach is bounded by sense, not by a rule — the mesh configures what can
|
||||
be configured, and a person's documents, projects and history are data under
|
||||
[ADR 0051](../../02-DECISIONS/0051-shared-data-is-the-operators.md), not configuration.
|
||||
|
||||
**A module names no node and no path.** The operator account is a node fact and the home is
|
||||
derived from it ([to-be 29](../../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) §1–2,
|
||||
shipped in the controller; its record is proposed in an open change). A module places a file
|
||||
*under the home, owned by the account*, and the same manifest lands on a server and a laptop.
|
||||
|
||||
## One default, varied by settings, never by edits
|
||||
|
||||
**One module, one default configuration.** The window manager module ships the configuration
|
||||
that is right for every node. There are no flavors: the predecessor's one desktop module carried
|
||||
four, one per class of machine, and what differed between them is what settings are for.
|
||||
|
||||
**A node varies a module in exactly two ways.** A **setting**, declared by the module with its
|
||||
type, meaning and default (proposed alongside the container-runtime records), set for the mesh
|
||||
or for one node, and rendered into the file at composition — the value is in the file, not in an
|
||||
environment variable the file reads. Or a **kept region**: a block in a file the mesh writes
|
||||
*into*, where the operator's own lines survive every push
|
||||
([ADR 0102](../../02-DECISIONS/0102-the-mesh-writes-into-a-shared-file-never-over-it.md)). An
|
||||
edit to a managed file outside such a region is not a third way; it is overwritten, as
|
||||
[ADR 0011](../../02-DECISIONS/0011-managed-files-are-generated-never-edited.md) says, and the
|
||||
predecessor's habit of adopting disk drift back into its database is not carried over.
|
||||
|
||||
The predecessor's theming — some ninety environment variables substituted into templates at sync
|
||||
time, with tools to list and set them — is the same idea with the wrong rendering. The knobs
|
||||
become declared settings; the file carries the value.
|
||||
|
||||
## Roles a machine has once are seats, and seats carry tools
|
||||
|
||||
**A role a machine fills at most once is a node-scoped seat**, declared by a module
|
||||
([ADR 0121](../../02-DECISIONS/0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md),
|
||||
[ADR 0126](../../02-DECISIONS/0126-a-module-declares-its-own-seats.md)): the login shell, the
|
||||
display session, the display server, the terminal emulator, the launcher, the notifier, the
|
||||
compositor, the lock screen, the service manager, the boot loader. Several modules may be able to
|
||||
hold one — zsh, fish and bash can all hold the login shell — and the assignment on each node says
|
||||
which does. Installing a shell is installing software; holding the seat is being *the* shell.
|
||||
|
||||
**A seat's contract is its tools** ([ADR 0132](../../02-DECISIONS/0132-a-seat-carries-the-tools-its-holder-must-serve.md)).
|
||||
Every holder of the login-shell seat serves `execute`, which takes one string, the command, and
|
||||
runs it on the node the seat is scoped to. Every holder of the boot seat serves "rebuild the boot
|
||||
images", so *"rebuild your boot images"* is a verb addressed to a machine, not a one-off step in
|
||||
a hook. Every holder of the service-manager seat answers for the units on the machine, system and
|
||||
user scope. A module may serve its own tools beside the seat's
|
||||
([ADR 0170](../../02-DECISIONS/0170-the-firewall-seat-serves-its-verbs.md) §2): show the rendered
|
||||
configuration, set a theme value, report status.
|
||||
|
||||
**Any tool may be called from any node.** The operator's statement, and the grant model it
|
||||
implies: the executor on each node may call everything, as the console already may. A verb that
|
||||
needs root on the machine is the module's concern — the tool escalates, the executor and the
|
||||
caller do not know.
|
||||
|
||||
## Servers and workstations differ by capability, not by catalogue
|
||||
|
||||
The same catalogue serves every node. A module declares what it needs — a graphical session, a
|
||||
display server, a container runtime — and the machine reports what it has, as the profile already
|
||||
reports eight capabilities today ([issue 160](../../04-ISSUES/160-a-machine-says-little-about-itself-and-only-when-asked/00-report.md)).
|
||||
Assignment refuses the wrong placement by name
|
||||
([ADR 0161](../../02-DECISIONS/0161-what-deserves-a-seat.md) §3). So every node takes the shell,
|
||||
the prompt, git and the agent; only a node with a graphical session can take the display server,
|
||||
and only a node holding the display server can take a window manager. Nothing in a module says
|
||||
"workstation".
|
||||
|
||||
## What the operator would say to the mesh
|
||||
|
||||
*Set the login shell on the build node to fish. Rebuild the laptop's boot images. Show me the
|
||||
window manager's effective configuration on the desktop and where each value comes from. Give
|
||||
the downloads folder on the laptop to the home server. Run `uptime` on every node.* Each of these
|
||||
is a seat verb or a module tool, addressed to a node, answered by whatever holds the role there.
|
||||
+91
@@ -0,0 +1,91 @@
|
||||
# 02 — What exists, and what is missing
|
||||
|
||||
*Measured 2026-10-02 on one installation: two workstations, two servers, all four converged to
|
||||
the mesh; the predecessor retired on the last workstation the day before. Numbers are from the
|
||||
machines and the repositories, not from memory.*
|
||||
|
||||
## 1. What the predecessor's desktop looks like
|
||||
|
||||
The predecessor's catalogue on the laptop held **34 modules**, of which **28** are the operator's
|
||||
environment rather than services. By what they declare:
|
||||
|
||||
| shape | count | examples |
|
||||
|---|---|---|
|
||||
| package only | 9 | browser, mail client, process monitor, media player, file manager, chat |
|
||||
| package + `/etc` files + system service | 5 | login manager, display server, power and thermal daemons, package manager configuration |
|
||||
| package + files under the home | 6 | shell and prompt, the agent at the terminal, scripts, the sync client, a music player |
|
||||
| files under the home + user units + hooks | 2 | the desktop environment, audio |
|
||||
| third-party organisation tooling | 6 | out of scope here |
|
||||
|
||||
**The desktop module alone** declares **88 files**, **4 flavors** (the window-manager stack, and
|
||||
one per class of machine), **2 user units** with a hook to enable them, 8 files under `/etc`, a
|
||||
wallpaper shipped as an asset, and reads **about 90 environment variables** as theme knobs,
|
||||
substituted into its templates at sync time and set through a theming tool. Its hook exists
|
||||
because *shipping a unit file does not run it*: one unit had been deployed for months and ran on
|
||||
one machine only, because somebody had enabled it there by hand.
|
||||
|
||||
**The shell module** ships `~/.zshrc`, the prompt configuration, an `~/.ssh/config` that the
|
||||
predecessor generated from its registry, and a `LOGIN_SHELL` variable applied with `chsh` by a
|
||||
hook. Two flavors: the prompt theme, and autocompletion.
|
||||
|
||||
**Other modules write into the desktop module's files.** The chat client places i3 and notifier
|
||||
snippets into `config.d` directories the desktop module owns, and its launch flags, window
|
||||
placement and notification colours are each a variable with a default.
|
||||
|
||||
**One-off steps live in hooks** across the set: enable user units, `chsh`, create a swap file,
|
||||
`mkinitcpio`, enable a vendor VPN service the package ships disabled. Every one is state the
|
||||
host could declare or a verb a seat could serve; none is today.
|
||||
|
||||
## 2. What the migration did with them
|
||||
|
||||
The migration's module to-do scoped the whole set out as *desktop / workstation ricing — the
|
||||
workstation's own environment* and *node/OS tooling — managed on the node, never catalogue*. The
|
||||
last workstation's runbook then split the same set three ways: **A**, system scope, which the
|
||||
host's vocabulary can express today (the login manager, the display server, the power daemons,
|
||||
the package manager, the container runtime); **B**, under a home or a user unit, waiting on
|
||||
to-be 29; **C**, package only, the operator's call. The migration log closes the workstation with
|
||||
*the operator's desktop awaiting its design*.
|
||||
|
||||
Two things followed from scoping them out. Nothing regenerates those files now, so a fix is a hand
|
||||
edit — the login manager's session script was fixed this way on the day of writing, and recorded
|
||||
in a repository nothing deploys from. And the one piece of this family written as a mesh module,
|
||||
the ssh client, was closed on hold in the catalogue until the controller carried the account fact.
|
||||
|
||||
## 3. What the records already give
|
||||
|
||||
| wanted | record | state |
|
||||
|---|---|---|
|
||||
| one module per managed thing; every module may have tools | [ADR 0040](../../02-DECISIONS/0040-what-a-module-is.md) | accepted; examples are services, and the shell is named as a *shared* seat |
|
||||
| a module declares its own node-scoped seat | [ADR 0121](../../02-DECISIONS/0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md), [ADR 0126](../../02-DECISIONS/0126-a-module-declares-its-own-seats.md) | accepted |
|
||||
| a seat's contract is its tools; a holder may add its own | [ADR 0132](../../02-DECISIONS/0132-a-seat-carries-the-tools-its-holder-must-serve.md), [ADR 0170](../../02-DECISIONS/0170-the-firewall-seat-serves-its-verbs.md) | accepted; one node seat serves verbs live |
|
||||
| a capability the machine reports gates a holder | [ADR 0161](../../02-DECISIONS/0161-what-deserves-a-seat.md) §3 | accepted; the profile already reports `graphical-session` |
|
||||
| the account as a node fact; a file under the home owned by it | [to-be 29](../../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) §1–2 | built in the controller; its record proposed in an open change |
|
||||
| inside a home: owned, written into, written by the module, found | proposed in the same change | proposed |
|
||||
| a setting declared with type, meaning, default and cost | proposed with the container-runtime records | proposed |
|
||||
| a managed file is derived; an edit is overwritten | [ADR 0011](../../02-DECISIONS/0011-managed-files-are-generated-never-edited.md) | accepted |
|
||||
| the mesh writes into a shared file, never over it | [ADR 0102](../../02-DECISIONS/0102-the-mesh-writes-into-a-shared-file-never-over-it.md) | accepted |
|
||||
| a module names no path; the host resolves the home | [ADR 0112](../../02-DECISIONS/0112-a-module-definition-names-no-node-mesh-or-path.md) | accepted |
|
||||
| the `user` shape: a login shell is declared state | [to-be 05](../../03-DESIGN/01-to-be/05-the-node-host.md) | designed; used by no module |
|
||||
|
||||
## 4. What is missing
|
||||
|
||||
1. **The account is recorded nowhere.** The node record has the column; on all four nodes it
|
||||
is empty. Every home-scoped module is unassignable until the operator states it.
|
||||
2. **User-scoped units.** The host's `service` shape has no user scope. To-be 29 says it
|
||||
plainly: *a workstation's per-user daemons have no form the mesh can send.* The desktop
|
||||
module's two units, the audio masks, the power module's memory guard and the thermal
|
||||
daemon's profile switcher all need it.
|
||||
3. **One-off steps.** `mkinitcpio`, `chsh`, creating a swap file. Each is either declared
|
||||
state the host lacks a shape for, or a verb a seat should serve. An action in a declaration
|
||||
is refused over the link, and rightly.
|
||||
4. **Settings leak** ([issue 168](../../04-ISSUES/168-a-setting-reaches-every-file-and-contribution/00-report.md)):
|
||||
a setting reaches every mergeable file and every contribution of its module. Ninety theme
|
||||
knobs on that mechanism would reach ninety files. The proposed settings record says a setting
|
||||
names the file it lands in; that has to ship first.
|
||||
5. **Where tools run.** Every module that serves a tool today does so from its own container
|
||||
per node. See [03](03-one-tool-executor-per-node.md).
|
||||
6. **A seat's verbs are undecided for every seat but three.** To-be 33 leaves which verbs each
|
||||
seat serves as *a decision per seat, slowly*. The environment adds a dozen seats.
|
||||
7. **Catalogue placement.** The media chain left this catalogue for its own; whether the
|
||||
environment does the same, and whether a third-party organisation's tooling belongs in a
|
||||
public catalogue, are unasked.
|
||||
@@ -0,0 +1,88 @@
|
||||
# 03 — One tool executor per node
|
||||
|
||||
*The direction the operator set on 2026-10-02, the evidence it rests on, and what it supersedes.
|
||||
A direction, not yet a decision: the record is written when this effort graduates.*
|
||||
|
||||
## Where tools are served today
|
||||
|
||||
[To-be 33](../../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md) names three families — a
|
||||
role's tools on the seat, a module's own tools on the module, the mesh's own verbs on the
|
||||
controller seat — and [ADR 0160](../../02-DECISIONS/0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md)
|
||||
says a runtime serves the subjects its membership issues. What *runs* that runtime is
|
||||
[ADR 0150](../../02-DECISIONS/0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md):
|
||||
one supervised process per module, under the module's own account, carrying that module's
|
||||
compiled tools. Measured on the live mesh:
|
||||
|
||||
| who answers | how it runs | count |
|
||||
|---|---|---|
|
||||
| the mesh's own verbs | the controller binary, on its node | 17 verbs |
|
||||
| the store seat | the store's own runtime | 2 verbs |
|
||||
| the packet-filter seat | **a container per node**, built on the tool-runtime base image, with the network namespace and `NET_ADMIN`, on all four nodes | 3 verbs and 1 own tool |
|
||||
| every module's own tools | the module's container, one per node it runs on | 67 tools across the catalogue |
|
||||
| the console | a container per node, loopback MCP, `invokes: *` | serves none, calls all |
|
||||
| the host | — | serves nothing; answers no question about the machine |
|
||||
|
||||
**The packet-filter holder is the case to look at.** The module is a package, three files and a
|
||||
system service. To serve three verbs it also declares a built image and a container on every
|
||||
node whose only job is to answer them. Scaled to the environment — a shell, a prompt, a launcher,
|
||||
a notifier, a compositor, a login manager, a service manager, a boot loader, a downloads folder —
|
||||
that is one container per module per node for software that is itself not a container, and the
|
||||
operator's judgement is that tools should not run inside a container at all.
|
||||
|
||||
## The direction
|
||||
|
||||
**One tool executor per node, on the host side.** A process the host supervises, the way the
|
||||
launcher supervises the host ([ADR 0005](../../02-DECISIONS/0005-the-node-host.md)): not a
|
||||
container, one bus credential for the node, module-agnostic. It loads the tool code of every
|
||||
module assigned to the node and serves each module's tools and each held seat's verbs on the
|
||||
subjects the membership issues — nothing changes in what [ADR 0159](../../02-DECISIONS/0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md)
|
||||
and [ADR 0160](../../02-DECISIONS/0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md)
|
||||
say about subjects, grants and memberships; what changes is that one process subscribes for the
|
||||
node instead of one per module.
|
||||
|
||||
- **A module brings its tools as a built artifact**, a bundle the pipeline produces, never an
|
||||
image. The executor knows bundles and subjects; it knows nothing of zsh or nftables.
|
||||
- **A tool is code the module wrote**, one function behind an MCP verb. `execute` on the shell
|
||||
seat is a function with a string argument. The executor does not declare, template or
|
||||
interpret tools; it runs them.
|
||||
- **Root is the module's concern.** A tool that must change the packet filter or rebuild boot
|
||||
images escalates itself. The executor does not run as root for everyone, and the caller does
|
||||
not know.
|
||||
- **Any node may call any tool on any node.** The executor's credential may call everything,
|
||||
as the console's already does; per-module grants on the calling side are not kept.
|
||||
- **The mesh's own verbs stay with the controller** ([ADR 0154](../../02-DECISIONS/0154-the-meshs-own-verbs-are-the-controller-seats-tools.md)),
|
||||
and a mesh-scoped seat's verbs run on the node that holds it
|
||||
([ADR 0121](../../02-DECISIONS/0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md)).
|
||||
No hub is added; the controller's node is already one.
|
||||
|
||||
**The console is the executor, renamed.** It already runs on every node with a credential that
|
||||
may call everything, and it already serves the mesh's tools to whoever is on the machine over
|
||||
MCP on loopback ([ADR 0152](../../02-DECISIONS/0152-the-operators-surface-is-a-module-the-console.md)).
|
||||
It moves out of its container into the host's process tree, gains the serving half, and takes a
|
||||
name that says what it is — *the node's tool runtime* or simply *node tools*; "console" names
|
||||
the operator's half only.
|
||||
|
||||
## What it supersedes, and what it keeps
|
||||
|
||||
| record | effect |
|
||||
|---|---|
|
||||
| [ADR 0047](../../02-DECISIONS/0047-a-module-runs-its-code-as-its-own-process-with-its-own-account.md), [ADR 0150](../../02-DECISIONS/0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md) | superseded *for tools*: one process per node runs every module's tool code, under one account. A module's long-running service — a daemon, a container — is untouched; the executor runs tools, not services. The record must say why one account for every module's tools is acceptable: every tool may be called from every node anyway, and root is taken by the tool, not granted to the process |
|
||||
| [ADR 0152](../../02-DECISIONS/0152-the-operators-surface-is-a-module-the-console.md) | kept in substance — a module, assigned per node, loopback MCP, the machine's login is the authority — changed in form: host-side, not a container; serves as well as calls; renamed |
|
||||
| [to-be 33](../../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md) §6, [to-be 34](../../03-DESIGN/01-to-be/34-the-console.md) | amended the same way |
|
||||
| [ADR 0170](../../02-DECISIONS/0170-the-firewall-seat-serves-its-verbs.md) §3, *a container may ask for a capability* | moot for that holder: the verbs run on the host side and escalate as they need |
|
||||
| the container-runtime seat, proposed in an open change: *the holder runs as a supervised process and serves the verbs locally to the host and on the bus* | consistent — a supervised process serving verbs is what the executor is; the open question is whether that holder keeps its own process or serves through the executor like everyone else |
|
||||
| the tool-runtime base image | no longer the way tools reach a node; may remain the way a module's *service* is built |
|
||||
|
||||
## What stays open
|
||||
|
||||
- **The executor's language.** The host is a static Go binary and loads no plugins, so the
|
||||
executor is a sibling process, and its language decides the language of every tool bundle.
|
||||
One decision, taken once.
|
||||
- **How a bundle reaches the node.** An artifact of the module's build, delivered as the host
|
||||
delivers everything else; whether it is a file resource in the declaration or a thing the
|
||||
executor fetches by digest.
|
||||
- **Reload.** A push that adds or upgrades a module's bundle reaches a running executor as a
|
||||
reload, not a restart, or every tool on the node blinks on every push.
|
||||
- **The host's own questions.** [Issue 160](../../04-ISSUES/160-a-machine-says-little-about-itself-and-only-when-asked/00-report.md)
|
||||
wants a machine to say more about itself. With an executor on every node, "what is this
|
||||
machine made of" is a seat verb like any other, served there.
|
||||
@@ -0,0 +1,65 @@
|
||||
# 04 — The seats of the environment
|
||||
|
||||
*Candidates, not decisions. To-be 33 says which verbs a seat serves is a decision per seat,
|
||||
taken slowly, because a seat's tools bind every future holder. This document lists the roles the
|
||||
operator's machine has once, who could hold each, what gates it, and a first verb or two — so
|
||||
each record has a starting point.*
|
||||
|
||||
## The rule for what is a seat here
|
||||
|
||||
A role the machine fills **at most once** is a node-scoped seat, declared by the module family
|
||||
that fills it ([ADR 0126](../../02-DECISIONS/0126-a-module-declares-its-own-seats.md)). A thing
|
||||
several of which coexist without contention — editors, browsers, media players — is not a seat;
|
||||
each is a module with its own tools, and nothing is singular about it. A seat is held by one
|
||||
assignment per node; other modules of the same family may be installed beside it without
|
||||
holding it ([ADR 0040](../../02-DECISIONS/0040-what-a-module-is.md) §1, read with the sharper
|
||||
distinction: *installed* is not *holding*).
|
||||
|
||||
## Candidate seats
|
||||
|
||||
| seat | holders | gated by | first verbs |
|
||||
|---|---|---|---|
|
||||
| **login shell** | zsh, fish, bash | nothing: universal | `execute(command)`; `show-config`; the holding itself sets the account's login shell through the host's `user` shape |
|
||||
| **service manager** | systemd | the `service-manager` capability the profile reports | units: list, status, start, stop, restart, enable, journal; **user scope** on each |
|
||||
| **boot** | grub, systemd-boot | a machine that boots itself (not a container host) | `rebuild-images`; `entries` |
|
||||
| **package manager** | pacman, apt | the `package-manager` capability | search, installed, upgrade, orphans; today a capability the host uses, not a seat anyone holds |
|
||||
| **display server** | xorg, wayland compositors that are their own server | the `graphical-session` capability | `displays`; `layout` |
|
||||
| **display session** | i3, sway | the display server seat held on the node; i3 needs x11, sway needs wayland | `reload`; `workspaces`; `windows`; `move` |
|
||||
| **terminal emulator** | xterm, alacritty, foot | display session | `open`; `font` |
|
||||
| **launcher** | rofi, dmenu | display session | `show`; `theme` |
|
||||
| **notifier** | dunst, mako | display session | `send`; `history`; `rule` |
|
||||
| **compositor** | picom | display server (x11 only) | `restart`; `effects` |
|
||||
| **lock screen** | i3lock, swaylock | display session | `lock` |
|
||||
| **bar** | i3status-rust, waybar | display session | `reload`; `blocks` |
|
||||
| **login manager** | lemurs, greetd | graphical session | `sessions`; `default-session` |
|
||||
| **audio** | pipewire, pulseaudio | the machine reports a sound device | `sinks`, `sources`, `default`, `volume`, `mute` |
|
||||
| **clipboard** | greenclip, cliphist | display session | `history`; `clear` |
|
||||
|
||||
Not seats, modules with their own tools: the editor, the browser, the mail client, the file
|
||||
manager, the media player, the chat client, the agent at the terminal, the downloads folder, the
|
||||
scripts folder, the sync client, the power and thermal daemons that are specific to one machine's
|
||||
hardware.
|
||||
|
||||
## What the table implies
|
||||
|
||||
**Capabilities come first.** `graphical-session`, `service-manager` and `package-manager` are
|
||||
reported today. *A display server is held* is not a capability but a seat being held, and a
|
||||
module that needs it declares a dependency on the seat, not on a capability: *i3 needs the
|
||||
display server seat held by xorg*. Whether a held seat can gate another's assignment is a
|
||||
question for the controller's resolver, and the first environment module after the shell will
|
||||
ask it.
|
||||
|
||||
**The service manager comes early.** Four of the predecessor's modules ship user units, and the
|
||||
executor itself is a unit. User scope on the host's `service` shape is a host change whichever
|
||||
module holds the seat; the seat's holder answers the questions about units, it does not apply
|
||||
them — the host does, as it does for every declared resource.
|
||||
|
||||
**The shell comes first.** Universal, no capability, one verb that is immediately useful on
|
||||
every node, and the `user` shape already makes the login shell declared state. It is the module
|
||||
that proves the pattern: a package, files under the home owned by the account, a seat claim,
|
||||
tools served by the executor, settings for the few things that vary per node, and a kept region
|
||||
for the operator's own lines.
|
||||
|
||||
**The login manager is the first system-scope one**, because it needs nothing new: a package,
|
||||
two files under `/etc`, a service — the same shape the ssh daemon module has today — and the
|
||||
session script it owns is the file that was hand-fixed the day this effort opened.
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
status: active
|
||||
initiated: 2026-10-02
|
||||
touches: [lab, the lab module, the catalogue, assignments, settings, the controller's store]
|
||||
became: []
|
||||
---
|
||||
|
||||
# 019 — A warm twin of the running mesh
|
||||
|
||||
## What is being investigated
|
||||
|
||||
Whether the lab can keep a **warm twin of the mesh as it actually runs**: the same machines, carrying
|
||||
the same catalogue, the same assignments and the same settings as the live mesh, raised once and kept
|
||||
ready, so that a change can be tested against the mesh as it is rather than against a scenario
|
||||
written to resemble it. A run against the twin would go through the lab module like any other run:
|
||||
a branch per repository, the twin restored from its snapshot, the change applied, the beds run.
|
||||
|
||||
## Why
|
||||
|
||||
The lab's beds raise meshes from declarations written for the bed. They prove the mechanism. They
|
||||
do not prove that a change works on the mesh that runs, with its accumulated assignments, its
|
||||
operator settings, its adopted machines and its modules in their real combinations. The gap showed
|
||||
on 2026-10-02:
|
||||
|
||||
- a change to how a module's settings reach its files was correct in every bed, and would have put a
|
||||
setting into the container runtime's configuration on every machine running that module. Only the
|
||||
composed plan for a real machine showed it;
|
||||
- a firewall change composed cleanly and still left one machine's wired port unfiltered, because
|
||||
of a link that machine had and no bed did;
|
||||
- a recovery step was needed on every machine at once, after a change that every bed had passed.
|
||||
|
||||
The lab already has a warm mode, a snapshot of a raised scenario restored between attempts. What it
|
||||
does not have is a scenario that **is** the running mesh, kept current with it.
|
||||
|
||||
## What it touches
|
||||
|
||||
- **What a twin is made of.** The catalogue and the assignments are records; settings are records;
|
||||
secrets are sealed to machines and cannot be copied. Which of these can be carried to the lab as
|
||||
they are, which must be substituted, and how a twin says what it substituted.
|
||||
- **Data.** A twin with the real catalogue and no real data proves composition and delivery, not a
|
||||
migration. Whether a twin carries data, a sample of it, or none.
|
||||
- **Keeping it current.** A twin raised once goes stale with the first merge. Whether it is
|
||||
re-derived from the live records on each run, refreshed on a schedule, or rebuilt only when asked.
|
||||
- **Machines.** The live mesh has machines of different kinds: a server on the internet, machines
|
||||
behind a home router, a laptop that sleeps. Which of their properties a twin must reproduce for a
|
||||
test to mean anything (reachability, the private network, the found firewall).
|
||||
- **Cost.** The lab machine's memory and disk, and how long a twin takes to raise from cold.
|
||||
- **The lab module's tools.** A run against the twin rather than a named bed: one more tool, or an
|
||||
argument to the run tool.
|
||||
|
||||
## Starting point
|
||||
|
||||
The lab module (ADR 0172) runs beds through the mesh, and the lab's warm mode already snapshots and
|
||||
restores a raised scenario. The beds that raise a machine shaped like one live machine from the
|
||||
catalogue are the nearest existing thing, and the first to compare against.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
status: graduated
|
||||
initiated: 2026-10-03
|
||||
touches: [the tool runtime, the catalogue's tool bundles, the controller's declaration composer, settings, own secrets, 03-DESIGN/01-to-be/38-building-the-operators-machine.md]
|
||||
became: [02-DECISIONS/0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md, 03-DESIGN/01-to-be/38-building-the-operators-machine.md]
|
||||
---
|
||||
|
||||
# 020 — What a bundled tool is given
|
||||
|
||||
## What is being investigated
|
||||
|
||||
How a module's tools, once they are a bundle the node's runtime loads
|
||||
([ADR 0175](../../02-DECISIONS/0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md),
|
||||
[ADR 0188](../../02-DECISIONS/0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)),
|
||||
learn the things their container used to be handed: where the module's configuration file is, where
|
||||
its token or password is, which port the service listens on, where a provision's address is written.
|
||||
A container is given these as an environment and mounts, composed by the mesh per module per machine.
|
||||
A bundle has no environment of its own: the runtime's process carries four words for every bundle it
|
||||
loads, and nothing per module ([design 38](../../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP4).
|
||||
|
||||
## Why
|
||||
|
||||
Two holders moved on 2026-10-03 — the packet filter and the intrusion prevention — and both could,
|
||||
because neither needs anything but a fixed path and root. Of the thirty-three modules whose tools
|
||||
still run as containers on the runtime's image, thirty-one are not like that: their environment
|
||||
names a configuration file, a credential file, a service address, a grants directory. Moving them
|
||||
one by one without a rule for this would give the mesh thirty-one answers to one question. The
|
||||
measurement and the options are in [01](01-what-the-containers-are-given.md).
|
||||
|
||||
## What it touches
|
||||
|
||||
The runtime (which hands a bundle what it is given), the composer (which resolves `${dir:…}` and
|
||||
`${port:…}` for a container today and would for a bundle), the manifest (where a bundle would say
|
||||
what it needs), and design 38, which records the gap and must say the rule once there is one.
|
||||
@@ -0,0 +1,86 @@
|
||||
# What the tool containers are given, measured
|
||||
|
||||
Counted 2026-10-03 in the catalogue, after the two holders moved.
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| modules whose tools still run as a container on the runtime's image | 33 |
|
||||
| tool containers among them (two modules run two) | 36 |
|
||||
| modules whose container's environment carries only the bus credential | 1 (the intrusion prevention, now moved) |
|
||||
| modules whose container's environment carries more | 32 — 31 still containers |
|
||||
|
||||
## What "more" is
|
||||
|
||||
Every value a container is given is one of five shapes. The reference kinds the composer resolves
|
||||
in those values, over the 36 containers: a module directory (`${dir:…}`) in all 36, a mesh-chosen
|
||||
port (`${port:…}`) in 12, a seat and an access grant once each.
|
||||
|
||||
1. **A file the mesh already places on the host, mounted in.** The module's configuration as
|
||||
JSON (`…_CONFIG_FILE`), its own secret (`…_TOKEN_FILE`, `…_PASSWORD_FILE`, `MESH_BROKER_FILE`),
|
||||
a provision's address and secret written for it. Every one is a path under one of the module's
|
||||
directories — its mesh state, its state, its grants, what it has written — mounted at a path of
|
||||
the container's choosing and named to the tool through the environment. **The file is on the
|
||||
host already; only the name under which the tool finds it is the container's.**
|
||||
2. **The service's address, with the port the mesh chose:** `http://127.0.0.1:${port:3000}`. The
|
||||
port is the composer's; the rest is the manifest's constant.
|
||||
3. **A provision's address as a constant string** (a database's URL on the module's own network
|
||||
name), paired with a mounted secret file from shape 1.
|
||||
4. **A directory of grants** (`MESH_RECEIVES`): shape 1 again, a directory rather than a file.
|
||||
5. **Literals the image needs:** a time zone, a user id, a memory limit. These belong to the
|
||||
service's container where one exists; a tool bundle needs none of them.
|
||||
|
||||
So the whole of what a bundled tool needs is: the paths of its module's directories on this
|
||||
machine, the ports the mesh chose for its module here, and the constants its own manifest wrote.
|
||||
Nothing a container had that a bundle cannot have; the mesh composes all three for the container
|
||||
today, per module per machine.
|
||||
|
||||
## What the runtime already has for it
|
||||
|
||||
- The SDK's tool contributor is `(env) => tools`, and `collectTools(env)` takes the environment to
|
||||
hand each contributor. The runtime calls it without one, so every contributor reads the process's
|
||||
— the four words. The hook for a per-module environment exists and is unused.
|
||||
- A launched bundle ([ADR 0188](../../02-DECISIONS/0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md))
|
||||
is spawned with the runtime's environment; the launch takes an environment argument.
|
||||
- The composer resolves `${dir:…}` and `${port:…}` for a container's `env` and `volumes`; the same
|
||||
resolution over a bundle's declaration is the same code.
|
||||
|
||||
## Options
|
||||
|
||||
**A. The bundle declares its environment on its artifact, and the mesh composes it as a
|
||||
container's.** The manifest's tools artifact gains `env`, resolved with the same references;
|
||||
values that were mount targets become the host-side paths directly (`${dir:mesh-state}/config.json`
|
||||
rather than `/run/config/config.json`). The controller composes one environment per bundle per
|
||||
machine into the runtime's declaration; the runtime hands it to the bundle's contributor and to a
|
||||
launched child, and to nothing else. *For:* the tool code does not change — it reads the same
|
||||
names; the conversion of the thirty-one is a mechanical move of the container's `env` with the
|
||||
mounts folded in; one rule, one place. *Against:* the runtime's process carries thirty-one
|
||||
environments in its declaration, and a bundle's environment is visible to the other bundles in the
|
||||
process unless the runtime keeps them apart, which it must — a tool that reads `process.env`
|
||||
instead of the environment it was handed would see its neighbours' paths.
|
||||
|
||||
**B. The runtime derives the environment from the module's placed manifest.** No new field: the
|
||||
runtime reads, for each module it serves, where that module's directories and ports are, and hands
|
||||
a conventional set of words. *For:* nothing to declare. *Against:* a convention the tool code must
|
||||
be rewritten to, thirty-one times; the runtime learns the composer's job; a module that names its
|
||||
file `config.json` and one that names it `settings.json` need different words anyway.
|
||||
|
||||
**C. Tools read their module's files through the bus** — ask the controller. *Against:* a tool
|
||||
that cannot start without the bus answering a question is a tool that fails in the one case the
|
||||
tools exist for, and a secret crossing the bus to reach a file already on the machine is a
|
||||
disclosure for nothing.
|
||||
|
||||
A is the one that keeps the tool code and the composer's vocabulary as they are, and names the one
|
||||
thing the runtime must add: an environment per bundle, kept apart. The thing to decide beside it:
|
||||
whether a bundle's environment may name a secret file at all, or whether secrets stay mounts in
|
||||
spirit — a path the tool reads, never a value in the environment — which is what every container
|
||||
does today and what A keeps if the rule says *paths, not values*.
|
||||
|
||||
## What a decision would have to say
|
||||
|
||||
- Where a bundle says what it is given (the artifact, option A), and that values are paths and
|
||||
constants, never a secret's content.
|
||||
- That the composer resolves it with the references it already has, per module per machine.
|
||||
- That the runtime hands each bundle its own environment and nothing of another's, and how that is
|
||||
checked: a test loading two bundles whose environments differ and asserting each sees only its own.
|
||||
- That the thirty-one move in one mechanical change after the rule lands, each proven by its tools
|
||||
answering from the runtime, and the registration gate then refuses the container shape for all.
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
status: graduated
|
||||
initiated: 2026-10-03
|
||||
touches: [the console, 03-DESIGN/01-to-be/34-the-console.md, the tool runtime, seats, assignments]
|
||||
became: [02-DECISIONS/0195-the-meshs-tools-are-found-by-address-not-announced-whole.md, 03-DESIGN/01-to-be/34-the-console.md]
|
||||
---
|
||||
|
||||
# 021 — Finding a tool in the mesh
|
||||
|
||||
## What was investigated
|
||||
|
||||
How an agent finds the one tool it needs among everything the mesh answers, and how a call names
|
||||
exactly what it asks — a role the mesh holds once, a role every machine holds, or one assignment of a
|
||||
module on one machine — rather than receiving the whole catalogue and a name that can mean several
|
||||
things.
|
||||
|
||||
## Why
|
||||
|
||||
The operator's observation on 2026-10-03: *Claude should not see all tools at once; they should be
|
||||
discoverable — and `postgres.list_databases` is wrong, asking one machine's postgres is not asking
|
||||
another's.* Measured the same day from the console's own answer:
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| tools announced to every session at its start | 228, in 110 KB |
|
||||
| names (module or seat prefixes) | 43 |
|
||||
| node seats' verbs, which require `node` | 22 |
|
||||
| modules with tools on more than one machine | 4 — fail2ban, nftables (every machine), postgres, mssql (two each) |
|
||||
| modules reported "not answering", most with no tools and several retired | 47 |
|
||||
|
||||
The two stateful modules on two machines are listed **once**, with `node` optional and *whichever
|
||||
answers* when it is left out — though their two instances hold different databases. Design 34 §3 says
|
||||
such a module is listed once per machine; the live console does not do that. The list is taken once
|
||||
per session, so a tool that arrives later is invisible until the client reconnects. And only Claude
|
||||
Code's own deferral of long tool lists keeps the 228 from the model's context; another MCP client
|
||||
would receive them whole.
|
||||
|
||||
## Options
|
||||
|
||||
1. **Keep the flat list; rely on the client to defer it.** Rejected: a property of one client, and it
|
||||
leaves the ambiguity and the stale list.
|
||||
2. **One flat tool per assignment** (`ace_postgres_list_databases`). Removes the ambiguity, multiplies
|
||||
the list, and runs into the API's tool-name limit (letters, digits, `_`, `-`, 64 characters).
|
||||
3. **A small fixed set of tools that walk the mesh's own structure**, with the full address as an
|
||||
argument: the mesh's seats; a machine's node seats and assignments; a search; a description; a
|
||||
call. Chosen — see [ADR 0195](../../02-DECISIONS/0195-the-meshs-tools-are-found-by-address-not-announced-whole.md).
|
||||
4. **MCP resources or prompts for discovery.** Clients support them unevenly, and an agent acts
|
||||
through tools; a resource it cannot be relied on to read is not a discovery path.
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
status: graduated
|
||||
initiated: 2026-10-03
|
||||
touches: [the tool runtime, the per-module containers, the SDK, the bus grants, 03-DESIGN/01-to-be/38-building-the-operators-machine.md]
|
||||
became: [02-DECISIONS/0198-a-modules-long-running-code-is-launched-by-the-node-runtime-and-reaches-the-bus-through-it.md, 03-DESIGN/01-to-be/38-building-the-operators-machine.md]
|
||||
---
|
||||
|
||||
# 022 — Where a module's long-running code runs
|
||||
|
||||
## What was investigated
|
||||
|
||||
Twenty-three modules still run their own code in a container built on the runtime's image. Their tools
|
||||
can move as bundles ([ADR 0192](../../02-DECISIONS/0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md),
|
||||
[ADR 0193](../../02-DECISIONS/0193-every-bundle-the-runtime-serves-is-launched-and-the-runtime-knows-no-language.md));
|
||||
the rest of what those containers run cannot yet. This asks where that code goes and how it reaches
|
||||
what its container handed it.
|
||||
|
||||
## What that code is, measured 2026-10-03
|
||||
|
||||
| | modules |
|
||||
|---|---|
|
||||
| subscribes to events on the bus | audit-logger (everything), mesh-catalog (two seat events), mesh-vault, records (`gitea.pull.merged`), and postgres, mongodb, mssql, redis, mosquitto logging their own lifecycle |
|
||||
| provisioners: read the grants the mesh delivered as files, act on the backend, emit | 12 |
|
||||
| a run-once preparation step | mesh-catalog |
|
||||
| a command-line client of the backend | psql, mosquitto_ctrl, git (packages on every machine's system); mongosh, sqlcmd (not in its repositories) |
|
||||
| a service reached by a container name | icecast, mailu-admin, minio, mongodb-server, mssql |
|
||||
| a main of its own | anthropic-consumer, openai-consumer, route-adapter |
|
||||
|
||||
A provisioner needs nothing a launched bundle lacks: files named by its words, its backend, and an emit
|
||||
that already travels through the runtime. The one thing missing is **a subscription** — events
|
||||
delivered to the module's code, acknowledged when it has handled them.
|
||||
|
||||
## Options
|
||||
|
||||
1. **The runtime launches it and is its bus**: the stdio channel gains a subscription; the runtime
|
||||
binds the module's durable consumer and delivers each event to the child, acknowledging when the
|
||||
child answers. One bus connection per machine; any language. Chosen.
|
||||
2. **A process per module with its own bus client and credential.** Every language's SDK would carry
|
||||
a transport and every module a credential on disk — what ADR 0188 rejected for tools, for the same
|
||||
reasons.
|
||||
3. **Keep the containers for this code.** Leaves ADR 0188's rule broken for 23 modules indefinitely.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
status: active
|
||||
initiated: 2026-10-03
|
||||
touches: [the seats, the seat protocol, the controller's ownership check, 03-DESIGN/01-to-be/26-the-seats.md]
|
||||
---
|
||||
|
||||
# 023 — A seat protocol that defines what its holder owns
|
||||
|
||||
## What is investigated
|
||||
|
||||
**A seat is a definition — a protocol — and a module occupies it by implementing that protocol.**
|
||||
Today the protocol is what the holder accepts, emits and serves (ADR 0118, 0129, 0132): its verbs, as MCP
|
||||
tool definitions. This asks whether the protocol should also name the **files and directories the
|
||||
holder owns**, so that occupying the seat means owning them: `node-resolver-config` owns
|
||||
`/etc/resolv.conf`, `node-hosts-file` owns `/etc/hosts`, the intrusion prevention owns its jail file.
|
||||
|
||||
The direction is the protocol's, not the holder's: the seat states what any holder must own; a module
|
||||
that wants the seat must declare those paths among its resources, or the controller refuses the claim
|
||||
as not implementing the seat. Two seats may not name one path.
|
||||
|
||||
## Why
|
||||
|
||||
Who owns a singular file is today answered by reading every manifest, and enforced only after the fact,
|
||||
when two modules on one machine both declare the same path. The question *which module owns
|
||||
`/etc/resolv.conf`?* came up on 2026-10-03 with no place to look it up. A seat that names the path answers
|
||||
it from the seat table, before any module is written, and makes "implements the seat" checkable.
|
||||
|
||||
## What it touches
|
||||
|
||||
- The seat definition and its table (ADR 0122) — a new part of the protocol.
|
||||
- The controller's ownership check (`checkResources`), which already refuses two modules owning one path.
|
||||
- Every node seat that is really about a file: `node-resolver-config`, `node-hosts-file`
|
||||
([ADR 0199](../../02-DECISIONS/0199-a-module-that-answers-names-declares-its-zone-and-a-nodes-hosts-file-is-one-modules.md)),
|
||||
`node-intrusion-prevention`, `node-packet-filter`.
|
||||
|
||||
Raised by the operator during the resolver work of ADRs 0194–0199 and parked there so that work was not
|
||||
widened by it.
|
||||
@@ -13,6 +13,14 @@ decisions taken over three days; the reasoning is kept, the fragmentation is not
|
||||
|
||||
The environment a change is run against before it reaches real machines.
|
||||
|
||||
> **Still the lab, no longer the test bed — 2026-09-30, by [ADR 0149](0149-the-live-mesh-is-the-test-bed.md).**
|
||||
> Everything here stands. What changed is what the lab is *for*: a change is verified against the mesh
|
||||
> that is running, because the faults that cost the most are faults of a mesh that already exists —
|
||||
> bound consumers, containers made against an older roster, an adopted machine — and a bed is by
|
||||
> construction a mesh that does not. Raising a mesh from bare is now the lab's whole job, which is the
|
||||
> one thing the live mesh cannot be asked to do. 0149 also supersedes
|
||||
> [ADR 0068](0068-the-lab-takes-requests.md), which extended this one and was never built.
|
||||
|
||||
## A node in the lab is a virtual machine
|
||||
|
||||
It boots a stock Linux image, runs the real install, and becomes a node. **It is not a model of
|
||||
|
||||
@@ -72,6 +72,12 @@ answers from it. Nothing flows back: this repository is public, the mesh is not,
|
||||
would be how installation-specific detail arrives into documents that must not carry it
|
||||
([`README.md`](../README.md)).
|
||||
|
||||
> **The mechanism changed — 2026-09-30, by ADR 0153.** What stands: read where it is written, no copy,
|
||||
> one-way. What moved: the reader is a module the mesh assigns (`records`, a checkout at a commit every
|
||||
> answer names) rather than the agent session of design 15, which is not built; and "the search consults
|
||||
> the agent" has no store to consult since the cut-over — the console's tool list is where the record
|
||||
> appears beside everything else. [ADR 0153](0153-the-record-is-read-by-a-module-and-the-console-lists-it.md).
|
||||
|
||||
## Consequences
|
||||
|
||||
**This repository stops being a fourth knowledge system, properly.** The original objection was
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
topic: building it
|
||||
status: proposed
|
||||
status: accepted
|
||||
date: 2026-09-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
@@ -101,3 +101,19 @@ the digest down after building.
|
||||
**Whether kind 4 deserves a module at all.** Thirty-five descriptions that say *install this and
|
||||
write these files* may be better as one module with settings than as thirty-five modules. Left
|
||||
open deliberately; it is a question about the shape of the catalogue, not about whether to have one.
|
||||
|
||||
## Accepted, 2026-09-29, against what was built
|
||||
|
||||
*Marked in a grooming pass: the mesh was built to this record and the record still said `proposed`.*
|
||||
|
||||
The proposal is the arrangement that exists. `mesh-catalog` holds descriptions of software we did
|
||||
not write and the programs that provision it, and holds neither the mesh's own components nor an
|
||||
application's own module. The mesh's list of modules is a table in the control plane, filled by
|
||||
`module add`, and every module records the source it came from with the commit it was read at.
|
||||
|
||||
**One half is not built: `module check` as a command on the control plane's binary.** A manifest is
|
||||
still validated by a test that reaches into the control plane's internals — which works for this
|
||||
catalogue and gives nothing at all to somebody describing their own application in their own
|
||||
repository, which this record says is the case that matters most. That is
|
||||
[issue 148](../04-ISSUES/148-a-manifest-outside-this-catalogue-has-no-check/00-report.md).
|
||||
|
||||
|
||||
@@ -8,6 +8,8 @@ reconstructed: false
|
||||
|
||||
# 39. What the SDK holds, and what it refuses
|
||||
|
||||
> **The mechanism changed — 2026-10-02, by [ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md).** The test of this record — frequent *and* cascading does not belong — stands and now applies to one SDK per language. Where *what it holds* names the broker client and the event consumer, read: the local protocol a tools bundle speaks to the node's runtime; the transport lives in the runtime and in no SDK, which is what keeps a bus change from rebuilding any module in any language.
|
||||
|
||||
_Reconciliation note (2026-09-05): supersedes the earlier "repository structure" decision, which the consolidation folded; no standalone record remains to point at, so body references to it now point at the nearest surviving record, [ADR 0015](0015-applications-live-in-their-own-repository.md)._
|
||||
|
||||
## Context
|
||||
|
||||
@@ -78,6 +78,8 @@ capability. The host hardcodes no firewall, supervisor, package manager or runti
|
||||
generic apply primitives and platform detection, so it runs where none of those exist — an Android
|
||||
phone has no ufw, systemd, pacman or Docker.
|
||||
|
||||
> **The mechanism changed — 2026-10-02, by [ADR 0176](0176-the-login-shell-is-a-node-seat-and-execute-is-its-contract.md).** The shell example above — *bash, zsh and fish all join `shell`; one may be default* — is read as *installed is not holding*: the three may all be installed, and the `login-shell` seat is node-scoped and held by exactly one. The decision — what a module is, and the three relationships — stands; [ADR 0173](0173-the-operators-machine-is-the-meshs-and-a-module-is-what-it-declares.md) applies it to the operator's whole machine.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **Supersedes the earlier "grouped by domain" decision** (folded in consolidation; see the
|
||||
|
||||
@@ -9,6 +9,8 @@ extends: 0043-a-module-broker-account-is-scoped-by-emits-and-consumes.md
|
||||
|
||||
# 47. A module runs its code as its own process, with its own account
|
||||
|
||||
> **The mechanism changed — 2026-10-02, by [ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md).** A module's *tools* are no longer served by the module's own process under its own account: one tool runtime per node, on the host side, serves every assigned module's bundle. A tool is still served on its own subject and only the module that serves it answers; what moved is the process and the account.
|
||||
|
||||
## Context
|
||||
|
||||
A module is one self-contained thing ([ADR 0040](0040-what-a-module-is.md)), and it gets a broker
|
||||
@@ -26,6 +28,14 @@ runtime is per-module, not per-node, and treating the audit-logger as special le
|
||||
modules' code with nothing to run it: the conversion produced tools and events that, as it stands,
|
||||
never execute.
|
||||
|
||||
> **The hosting form is settled elsewhere — 2026-09-30.** Where this record says "a container", read
|
||||
> [ADR 0150](0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md): a module's own
|
||||
> code runs as supervised processes under this record's one account. Nothing else here changes — the
|
||||
> per-module runtime, the per-tool key and the single scoped account are the argument this record made
|
||||
> and they are why 0150 goes the way it does. The note is here because two design documents chose the
|
||||
> other form without knowing this record existed
|
||||
> ([issue 117](../04-ISSUES/117-a-modules-own-code-is-a-container-and-a-process/00-report.md)).
|
||||
|
||||
## Decision
|
||||
|
||||
### A module with tools or events runs a process of its own
|
||||
|
||||
@@ -204,3 +204,14 @@ only, the refresh token only, the manager node only.**
|
||||
record extends, amended to describe the adapter generalisation.
|
||||
- The read-only vendor-agnostic analysis, 2026-09-05 (code workspace) — the inventory and the decisions
|
||||
taken on the open questions this record encodes.
|
||||
|
||||
> **The mechanism changed — 2026-10-02, by [ADR 0183](0183-the-anthropic-licence-manager-is-a-module-and-hands-tokens-to-the-agent-over-the-bus.md).**
|
||||
> What stands: `model-access` is one vendor-blind provision for the consumers that do not care which
|
||||
> vendor answers; a vendor's lifecycle is an adapter's; the carve-out that one node holds a refreshable
|
||||
> grant's refresh token readably. What moved: the Anthropic adapter is no longer a part of the
|
||||
> controller's licences context but a module, `claude-licence-manager`, holding the seat
|
||||
> `anthropic-licence-manager`, with the grants in its own store encrypted with a key the vault made for
|
||||
> it; and the agent at a terminal is not a consumer of `model-access` — it is coupled to an Anthropic
|
||||
> grant and uses the seat. The consequence above that the three binding columns *become three ordinary
|
||||
> consumers of `model-access`* therefore no longer describes the agent's bindings; they are the
|
||||
> manager's. The static-key adapters and the vendor-blind records stay where this record put them.
|
||||
|
||||
@@ -9,6 +9,13 @@ extends: 0007-connectivity.md
|
||||
|
||||
# 66. Public routing is name-agnostic, its names are resolved inside the mesh, and an internal authority can certify them
|
||||
|
||||
> **Narrowed, not replaced — 2026-10-03.** One clause of the decision below no longer holds: *publishing
|
||||
> a granted name into internal resolution, mesh-wide*. A public name now resolves publicly, and only
|
||||
> names under the mesh's own suffix get a private answer — [ADR 0191](0191-the-meshs-resolver-holds-only-the-meshs-own-names.md).
|
||||
> Inside the mesh a route is reached and certified by its internal name
|
||||
> ([ADR 0151](0151-a-routes-internal-name-is-composed-under-the-node-that-serves-it.md)). The label, the
|
||||
> node's public domain and their composition stand as decided here.
|
||||
|
||||
## Context
|
||||
|
||||
**[ADR 0007](0007-connectivity.md) and [connectivity §3](../03-DESIGN/01-to-be/08-connectivity.md)
|
||||
@@ -80,6 +87,15 @@ reaching the routed name, which the clause above has just made resolvable inside
|
||||
three are one decision: **compose the name, propagate it, certify it** — each is meaningless without
|
||||
the one before it.
|
||||
|
||||
> **The mechanism changed — 2026-09-30, by [ADR 0148](0148-the-meshs-names-are-resolved-not-copied-into-containers.md).**
|
||||
> A routed name still reaches every asker in the mesh, which is what this record decided and it stands.
|
||||
> It no longer reaches them by being written into each declared container: copying the roster in made the
|
||||
> roster part of every container's identity, so one name moving replaced every container in the mesh
|
||||
> ([issue 151](../04-ISSUES/151-a-new-name-recreates-every-container-in-the-mesh/00-report.md)). A
|
||||
> container resolves through its machine's resolver instead. The consequence below — that an internal
|
||||
> issuer's challenge needs the routed name resolvable inside the mesh — holds unchanged, by the means the
|
||||
> machine itself already uses.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **Lab-versus-production is one node-level `public-domain` setting**, not an override on every
|
||||
|
||||
@@ -1,14 +1,21 @@
|
||||
---
|
||||
topic: building it
|
||||
status: proposed
|
||||
status: superseded
|
||||
date: 2026-09-12
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 0016-the-lab.md
|
||||
superseded-by: 02-DECISIONS/0149-the-live-mesh-is-the-test-bed.md
|
||||
---
|
||||
|
||||
# 68. The lab takes requests, one at a time, and runs each from its own copy
|
||||
|
||||
> **Superseded — 2026-09-30, by [ADR 0149](0149-the-live-mesh-is-the-test-bed.md).** Never built. The
|
||||
> live mesh became the test bed, because the faults that cost the most are faults of a mesh that
|
||||
> already exists — bound consumers, containers made against an older roster, an adopted machine — and a
|
||||
> bed is by construction a mesh that does not. The rule worth keeping from below is that a run reads a
|
||||
> copy that is not anybody's working tree.
|
||||
|
||||
## Context
|
||||
|
||||
**The lab is exclusive hardware, and today a person holds it.** Raising a scenario takes over
|
||||
|
||||
@@ -35,6 +35,16 @@ The development cycle is enforced mechanically, to the extent frontmatter can ca
|
||||
capability existed" is an answer).
|
||||
- **No silent graduation** — a `graduated` research overview says what it `became:`, and the
|
||||
targets exist.
|
||||
- **No two records answering to one number** — added 2026-09-30; see the insight below.
|
||||
|
||||
> **Progressive insight — 2026-09-30.** The list above named four things `cycle.py` enforces, and
|
||||
> now names five. Nothing enforced that two issue records hold different numbers: two machines
|
||||
> filing issues within one hour both read `main`, both took "the next free number", and collided
|
||||
> twice — the second collision reaching `main` with `records.py`, `cycle.py` and `index.py` all
|
||||
> reporting success (04-ISSUES/155). A number is how every other record cites one, so two records
|
||||
> answering to it is a citation that resolves to whichever folder the reader opened. `cycle.py`
|
||||
> refuses it now. The decision here stands exactly as written: this is one more thing frontmatter
|
||||
> and file names can carry, found by its absence rather than by reasoning.
|
||||
|
||||
[`00-META/checks/cycle.py`](../00-META/checks/cycle.py) refuses violations, beside `records.py`
|
||||
and `index.py`; all three run before any merge here. What frontmatter cannot see — that code work
|
||||
|
||||
@@ -106,3 +106,14 @@ is refused with the candidates named, never resolved by picking.
|
||||
gap, and the day-one evidence.
|
||||
- [`03-DESIGN/01-to-be/23-choosing-a-provider.md`](../03-DESIGN/01-to-be/23-choosing-a-provider.md)
|
||||
— the design.
|
||||
|
||||
> **Widened, 2026-10-01 (issue #258).** The pin named a node, on the reasoning that "the same
|
||||
> module on two machines is two answers, and which machine is the whole question". Half right:
|
||||
> two modules on one machine can both answer a provision — `public-acme` and `step-ca` both offer
|
||||
> `acme-ca` on novox — and then which *module* is the whole question, and a node alone cannot ask
|
||||
> it. A provider is a (node, module) pair ([design 23](../03-DESIGN/01-to-be/23-choosing-a-provider.md)),
|
||||
> and a pin now names the pair: `pin <node> <provision> <from-node> <module>`. The resolver
|
||||
> refuses a node that answers twice instead of taking the last one listed, and refuses two
|
||||
> providers beside the consumer instead of settling them by a map walk — the same stance design 23
|
||||
> takes: ambiguity is refused, never resolved by picking. Records made before are completed by
|
||||
> migration where the node they name answers once. mesh-controller: `feat/pin-names-the-provider`.
|
||||
|
||||
@@ -47,6 +47,14 @@ Anything with the control plane in reach can ask any module anything it serves.
|
||||
harder: nothing outside the control plane can, and the control plane's connection is one more
|
||||
thing on the path of every question — a cost accepted for the audit it buys.
|
||||
|
||||
> **The mechanism changed — 2026-09-30, by ADR 0152.** What stands: `ask` on the control plane, and
|
||||
> that every call passes an account whose permission list says what it may ask. What moved: "nothing
|
||||
> outside the control plane can" stopped being true when a person's account gained a publish grant per
|
||||
> tool (design 25 §7, 2026-09-28), and [ADR 0152](0152-the-operators-surface-is-a-module-the-console.md)
|
||||
> takes the first option above for a module as well — a manifest declares `invokes`, and the bus grants
|
||||
> exactly that publish side. The audit the second option bought is the bus's permission list, which
|
||||
> derives both.
|
||||
|
||||
## How it is checked
|
||||
|
||||
A tools-only bed asks a served tool through the control plane and asserts an answer arrived —
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: proposed
|
||||
status: accepted
|
||||
date: 2026-09-25
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: proposed
|
||||
status: accepted
|
||||
date: 2026-09-25
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
@@ -275,3 +275,21 @@ On acceptance, each of these is superseded or amended by this record, not edited
|
||||
everything a module needs is a requirement
|
||||
- [Issue 095](../04-ISSUES/095-a-module-assigned-after-genesis-has-no-broker-account/00-report.md),
|
||||
[issue 103](../04-ISSUES/103-a-container-is-not-recreated-when-a-file-it-reads-changes/00-report.md): what fails today
|
||||
|
||||
## Accepted, 2026-09-29, against what was built
|
||||
|
||||
*Marked in a grooming pass.* The vault is a module providing `secret` at mesh scope, and six
|
||||
modules in the catalogue require it — so a shared secret is a requirement answered by the vault,
|
||||
which is what this record asks for. Private keys are still made where they are used and never
|
||||
travel, which is the other half and was never in question.
|
||||
|
||||
|
||||
> **The mechanism changed — 2026-10-02, by [ADR 0183](0183-the-anthropic-licence-manager-is-a-module-and-hands-tokens-to-the-agent-over-the-bus.md).**
|
||||
> What stands: every shared secret the mesh makes is the vault's, a private key is made where it is
|
||||
> used, and a long-lived value a backend issues enters the vault's custody — here as the key the vault
|
||||
> makes for the licence manager, which encrypts the vendor's grants at rest with it. What this record
|
||||
> did not foresee: a credential that lives hours, issued by a vendor to the one module that holds its
|
||||
> grant, and handed by that module to the agent on each node sealed to that node's module key, on
|
||||
> request/reply over the bus, never through the vault and never as a file the host writes. ADR 0183
|
||||
> states that as a bounded exception — one vendor, tokens that live hours, one recipient per message —
|
||||
> and a second such channel is a decision of its own.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: proposed
|
||||
status: accepted
|
||||
date: 2026-09-26
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
@@ -163,6 +163,14 @@ value, the requirement is marked not rotatable by the mesh, and a rotation is re
|
||||
**The number of parties decides, never the provider.** The resolver knows it from the requirement's
|
||||
recipients, leaving out the vault's custody copy, so no definition declares it.
|
||||
|
||||
> **Progressive insight — 2026-10-01.** The number of parties is the resolver's to know; *which form*
|
||||
> a single party's credential takes is not, and cannot be: whether a module reads its secret when it
|
||||
> starts or applies it once to a backend is a fact about the software, visible nowhere in the graph.
|
||||
> So the definition declares that half — `taken: at-start` or `taken: applied` on an own secret — and
|
||||
> a secret that declares neither is not rotated, refused with the word to write (issue 180). The
|
||||
> read-at-start form is built; the staged form for an applied credential is not. The decision stands;
|
||||
> the sentence above was one fact short.
|
||||
|
||||
### Until an adapter can
|
||||
|
||||
**An adapter that cannot yet ensure a second credential says so.** The two-party credentials it applies
|
||||
@@ -189,6 +197,23 @@ On acceptance, each of these is amended by this record, not edited:
|
||||
credential is no longer all-or-nothing with a window. It overlaps, with each step confirmed.
|
||||
A single-party credential is staged, not replaced.
|
||||
|
||||
## Accepted, 2026-09-30, and not scheduled
|
||||
|
||||
Accepted as written. The separation it draws — a consumer's *resource* and a *credential that reaches
|
||||
it* are different things with different lifecycles — is the part that had to be settled, because the
|
||||
alternative is what the record was written against: retiring a credential taking the data it reached
|
||||
with it. That is a data-loss shape, and a record that names it should not sit unresolved while the
|
||||
code that could hit it is being written.
|
||||
|
||||
**It is not built, and accepting it does not schedule it.** The SDK's provisioner adapter is still
|
||||
`create` / `remove` / `holds` rather than the four operations above, and no provider implements the
|
||||
two-credential rotation. Accepted-and-not-built is an ordinary state here — 0141 and 0142 are both in
|
||||
it — and it is the honest one: leaving this `proposed` made it invisible to anyone reading what the
|
||||
mesh has decided, while changing nothing about what runs.
|
||||
|
||||
The work it implies belongs with the provisioner contract, beside
|
||||
[issue 124](../04-ISSUES/124-a-consumer-cannot-be-told-what-its-provider-derived/00-report.md).
|
||||
|
||||
## Consequences
|
||||
|
||||
- **Every credential provider's adapter changes**, in two steps. The first separates *retire a
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: proposed
|
||||
status: accepted
|
||||
date: 2026-09-26
|
||||
deciders: jochen
|
||||
extends: 0112-a-module-definition-names-no-node-mesh-or-path.md
|
||||
@@ -47,3 +47,10 @@ other boundary already is: the module name.
|
||||
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.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ extends: 0102-the-mesh-writes-into-a-shared-file-never-over-it.md
|
||||
## Context
|
||||
|
||||
When a resource stops being declared — its module unassigned, the node sent a
|
||||
deliberately-empty declaration ([issue 127](../04-ISSUES/127-a-declaration-that-shrinks-to-empty-is-skipped-not-sent/00-report.md)),
|
||||
deliberately-empty declaration ([issue 149](../04-ISSUES/149-a-declaration-that-shrinks-to-empty-is-skipped-not-sent/00-report.md)),
|
||||
or a new catalogue version renaming its id — the host undoes it. The host's own code states
|
||||
the rule it means to follow: **it removes what it made and leaves what it merely configured.**
|
||||
For almost every resource it does exactly that:
|
||||
|
||||
+11
-1
@@ -9,6 +9,14 @@ extends: 0110-a-seat-is-a-module-assignment-from-a-closed-set.md
|
||||
|
||||
# 121. A system seat is named for its scope, and a module may define its own
|
||||
|
||||
> **Narrowed, not replaced — 2026-10-03.** *"`the-dns-port` → `node-dns-resolver`"* no longer holds:
|
||||
> the serving role moves to mesh scope as `mesh-resolver`, one per mesh, and `node-dns-resolver` is
|
||||
> retired ([ADR 0194](0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md)). The
|
||||
> distinction this record kept — serving and asking are two roles, two seats — stands, and
|
||||
> `node-resolver-config` is unchanged.
|
||||
|
||||
> **The mechanism changed — 2026-10-02, by [ADR 0190](0190-a-seats-work-is-shared-by-its-holders-and-building-is-the-first-such-role.md).** The naming rule stands. The build role this record made mesh-scoped — *the mesh's single build machine* — is node-scoped now: `node-build-agent`, one holder per machine, every holder taking from one work queue.
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0110](0110-a-seat-is-a-module-assignment-from-a-closed-set.md) made seats a closed set the
|
||||
@@ -81,7 +89,9 @@ closed set stays what its name says it is: the *system's* roles, not everyone's.
|
||||
- **`the-uplink` → `node-uplink`** ([ADR 0125](0117-a-machines-uplink-is-a-seat.md)). Unheld, so it
|
||||
renames with no migration.
|
||||
- **The registry seats — `the-artifact-store`, `npm-package-registry` (→ `mesh-artifact-store`,
|
||||
`mesh-npm-package-registry`) — and `git` (→ `mesh-git`) — are decided but deferred.** They each
|
||||
`mesh-npm-package-registry`) — and `git` (→ `mesh-git`) — are decided but deferred.** *(The
|
||||
mechanism changed — 2026-09-30, by ADR 0156: `the-artifact-store` is renamed, one update and one
|
||||
alias under ADR 0122; the other two stay deferred.)* They each
|
||||
*deliver* a provision, so renaming them is a delivering-seat migration: a holder that stops
|
||||
resolving mid-flight takes a provision away from every consumer. That risk is not worth carrying in
|
||||
the same pass as the node-* renames, so they keep their names until done deliberately.
|
||||
|
||||
@@ -0,0 +1,159 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: superseded
|
||||
date: 2026-09-28
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0052-a-step-that-runs-once-before-a-container.md
|
||||
superseded-by: 02-DECISIONS/0135-a-module-version-prepares-its-state-before-it-runs.md
|
||||
---
|
||||
|
||||
# 133. A module owns its migrations, and the mesh owns when they run
|
||||
|
||||
## Context
|
||||
|
||||
On 2026-09-28 the mesh replaced its own control plane, through its own upgrade path, with a build
|
||||
carrying a migration. Nothing applied it. For the next three quarters of an hour every build the mesh
|
||||
made was refused by the store with one line — *column "built_contexts" does not exist* — which reached
|
||||
only whoever happened to be waiting on that build's reply. The images were built and published, so the
|
||||
registry filled with artifacts the mesh has no record of, and the overview went on reporting that every
|
||||
module was current ([issue 133](../04-ISSUES/133-the-control-planes-schema-is-migrated-at-birth-and-never-again/00-report.md)).
|
||||
|
||||
The schema had been created once, at genesis, by an action in the foundation bundle. Nothing ran it
|
||||
again, through many updates of the control plane since.
|
||||
|
||||
**The mechanism to do this right already existed and one module used it wrong.**
|
||||
[ADR 0052](0052-a-step-that-runs-once-before-a-container.md) makes a run-once container a step the host
|
||||
runs to completion before whatever the declaration places after it, and names migrating a schema as the
|
||||
case it exists for. Three facts about how it is used today:
|
||||
|
||||
- The control plane's manifest had no step at all. The immediate fix was to write one by hand, and that
|
||||
hand-written step repeats three environment variables and three volume mounts from the server
|
||||
resource it precedes — six chances to drift from the thing it prepares.
|
||||
- Two other modules hand-write the same shape for the same reason: gitea's admin bootstrap and
|
||||
mosquitto's dynsec seed, each repeating its sibling's image, environment and mounts. One of them
|
||||
ends in `|| true`, which is a lock implemented as a shrug.
|
||||
- The catalogue module takes the other road: it migrates its own schema in its own code when it starts.
|
||||
That failure mode is a crash loop rather than a stop — the catalogue restarted 338 times this
|
||||
morning on an unrelated start-time failure, and nothing anywhere said the mesh's graph had a gap.
|
||||
|
||||
**What the mesh already has, and what HAL needed stages for.** Ordering a provider before its consumer
|
||||
is `providersFirst`, which topologically orders a node's modules. Ordering within a module is
|
||||
declaration order, and a run-once container gates everything after it. Remembering that a step has
|
||||
already run is the digest of its declaration, recorded only after it exits 0
|
||||
([ADR 0018](0018-a-picture-is-read-from-what-runs.md)) — and the image is part of that digest, so a new
|
||||
build re-runs it. Three of the four things a stage system provides are therefore already here. The
|
||||
fourth — that a module has a schema at all — is the only thing missing.
|
||||
|
||||
**Nothing in the catalogue ships a migrations directory.** Of 72 modules, none has one; the modules that
|
||||
migrate do it in their own code. So this is not a decision about where SQL files live. It is a decision
|
||||
about who runs them and when.
|
||||
|
||||
**Two facts bound what is safely expressible.** A node converges toward its own declaration without
|
||||
waiting on any other node. And of the five modules that run on more than one machine today — dnsmasq,
|
||||
fail2ban, networking, networkmanager, sshd — not one wants a store; every module with a database is on
|
||||
exactly one machine.
|
||||
|
||||
## Decision
|
||||
|
||||
**A container may declare steps to run before it.** The same container, run to completion, with
|
||||
different arguments, in order, before it starts. The mesh derives the run-once resources from that
|
||||
declaration, so the image, the environment, the volumes, the network and the credentials come from the
|
||||
one place they are already described and cannot drift from it.
|
||||
|
||||
**A module's migrations are the first user of this, and the module owns them entirely.** The SQL, the
|
||||
order, the idempotence, the lock, and which dialect it speaks. The mesh never learns that postgres and
|
||||
mssql differ, because it runs the module's own image with the module's own arguments against the
|
||||
module's own binding and requires exit 0. A module needing both stores runs one step that does both.
|
||||
|
||||
**The mesh owns the moment, and the gate is the guarantee.** Whether a version may serve when its
|
||||
schema is not there yet is a deployment question, and the mesh is the only thing that can answer it,
|
||||
because the mesh is what starts the container. A step that fails stops the container it precedes, so
|
||||
a failed migration is a version that does not serve rather than a version serving against a store it
|
||||
does not match.
|
||||
|
||||
**Per node, and there is no level.** The step runs wherever the module runs. A step that ran "once,
|
||||
somewhere" would leave every other machine with no gate at all, and additive migrations protect old
|
||||
code against a new schema, never new code against an old one. The cost is an obligation a migration
|
||||
runner already carries: a version table and a lock.
|
||||
|
||||
**"Once, mesh-wide" is what holding a seat means.** A step that is not idempotent — seeding an
|
||||
account, sending a notice, taking a backup — belongs to a module that holds a seat, where the mesh
|
||||
already guarantees one holder, on record, handed over deliberately. That is the answer to the level
|
||||
question rather than a field that has to invent an election and keep it somewhere.
|
||||
|
||||
**Migrations are forward-only and additive.** The step runs before the *new* container starts, so the
|
||||
old one is still running against the new schema for the length of the apply.
|
||||
|
||||
**Declared, never inferred.** The control plane cannot see inside an image, so a module that ships
|
||||
migrations and declares no step is not refusable at registration; it breaks on its first upgrade. This
|
||||
record says so rather than implying a check that cannot exist.
|
||||
|
||||
## Options considered
|
||||
|
||||
1. **Each module migrates itself when it starts** — what the catalogue does today. Rejected: it turns a
|
||||
schema failure into a crash loop instead of a stop, it is invisible in the declaration so nothing can
|
||||
say the module even has a schema, and two machines running the module both migrate at start with
|
||||
nothing sequencing them.
|
||||
2. **The mesh applies migrations itself**, with a driver and a version table per store — HAL's shape.
|
||||
Rejected: the mesh would have to know one store type from another, hold another module's store
|
||||
credentials, and reach a machine to use them, which [ADR 0005](0005-the-node-host.md) forbids. It is
|
||||
also the reason that shape needs levels: something central has to decide where the once happens.
|
||||
3. **A hook lifecycle** — pre-build, post-build, pre-deploy, post-deploy. Rejected: there is no deploy
|
||||
event here to hook. A declaration is a desired state applied in order and reconciled forever, so
|
||||
"pre-deploy" is exactly "a step before this container", pre- and post-build are what a Dockerfile and
|
||||
the artifact list already are, and "post-deploy" has no moment to name.
|
||||
4. **A hook level** — once per module, or once per module-node assignment. Rejected as a field, kept as
|
||||
a property: see the decision. A once-per-module step needs cross-node ordering underneath it to be
|
||||
safe, and a node converging without waiting on its neighbours is worth losing on purpose rather than
|
||||
by accident.
|
||||
5. **Every module hand-writes its own run-once step** — the immediate fix for the control plane.
|
||||
Rejected as the general answer: it duplicates the resource it precedes, in three places already, and
|
||||
a hand-written step is one the next module forgets. Forgetting it is the fault this record exists
|
||||
for.
|
||||
6. **Record a schema level per module in the store.** Rejected: gating makes the invariant true by
|
||||
construction, so a level is a second account of the same fact and the first one to go stale.
|
||||
|
||||
## Consequences
|
||||
|
||||
**Three hand-written steps collapse into one line each**, and the control plane's own migrate step stops
|
||||
repeating its server's environment and mounts.
|
||||
|
||||
**The catalogue's self-migration becomes the exception to remove.** One shape, and the mesh's own
|
||||
control plane is not an exception to it either.
|
||||
|
||||
**A module on two machines with one shared store must lock.** Today none is, so this is an obligation
|
||||
stated before it is needed rather than discovered by two concurrent migrations.
|
||||
|
||||
**There is still no readiness-gated step.** Only an action carries `verify`; a container has no health
|
||||
notion, so "run this once the service answers" remains unexpressible and seeding through a running
|
||||
service's API has no home. That is its own decision about a container's readiness, and this record does
|
||||
not make it.
|
||||
|
||||
**Genesis keeps its own action.** At birth there is no control plane to derive anything from, which is
|
||||
what [ADR 0067](0067-genesis-is-a-pivot.md) already says about that moment.
|
||||
|
||||
## How this is checked
|
||||
|
||||
- **The composition carries the step.** A test on a node's composed declaration: every container that
|
||||
declares steps before it is preceded by them, and the derived step's image, environment, volumes and
|
||||
network equal the container's — so the two cannot drift, which is the failure the hand-written kind
|
||||
has.
|
||||
- **A failed step stops what follows.** The host already refuses to go on past a run-once step that did
|
||||
not exit 0; the test for that is extended to a derived one, so the gate is checked rather than
|
||||
assumed.
|
||||
- **The mesh's own schema is covered by the same mechanism as everything else.** The control plane
|
||||
declares its step in its own manifest, so the case that failed on 2026-09-28 is the case the test
|
||||
covers.
|
||||
- **A module claiming a seat for a once-only step is checked where seats are checked** — the conditions
|
||||
of holding, not a new mechanism.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0052](0052-a-step-that-runs-once-before-a-container.md) — the step this extends
|
||||
- [ADR 0018](0018-a-picture-is-read-from-what-runs.md) — a digest is the record that something happened
|
||||
- [ADR 0005](0005-the-node-host.md) — the control plane decides and never touches a machine
|
||||
- [ADR 0067](0067-genesis-is-a-pivot.md) — why genesis does it differently, once
|
||||
- [issue 133](../04-ISSUES/133-the-control-planes-schema-is-migrated-at-birth-and-never-again/00-report.md) — the failure that produced this record
|
||||
- [`03-DESIGN/01-to-be/32-what-a-module-declares.md`](../03-DESIGN/01-to-be/32-what-a-module-declares.md) §6 — the lifecycle this sits in
|
||||
- Measured 2026-09-28: three hand-written run-once steps repeating their sibling's resource; 0 of 72 modules with a migrations directory; 5 modules on more than one machine, none of them wanting a store
|
||||
@@ -0,0 +1,126 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-09-28
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
---
|
||||
|
||||
# 134. The mesh says what it applied
|
||||
|
||||
## Context
|
||||
|
||||
The pipeline is observable on the bus from a merge to an artifact, and modules already plug into it:
|
||||
the forge emits `pull.merged`, the build machine's seat emits `built`, the catalogue emits `registered`,
|
||||
`upgraded` and `rebuild-needed`, providers emit `postgres.database.provisioned` and its siblings. Things
|
||||
consume them today — the catalogue consumes `built`, each provider consumes its own provisioning events,
|
||||
model-usage consumes `*.usage.*`, the audit logger consumes `**`. Nothing had to be invented for any of
|
||||
that; subscribing *is* plugging in.
|
||||
|
||||
**It goes dark at the moment it touches a machine.** A host applies a declaration and reports to the
|
||||
control plane on the control branch, which only the control plane may read — correctly, because a report
|
||||
carries what a machine is and enrolment travels the same way. So nothing on the mesh says *this machine
|
||||
now runs version Y of module Z*, or that it refused to, or why.
|
||||
|
||||
What that cost on 2026-09-28, in one morning:
|
||||
|
||||
- A build result the store refused was visible only to whoever was waiting on that build's reply. For
|
||||
three quarters of an hour the mesh built things and recorded none of them, while the overview said
|
||||
every module was current ([issue 133](../04-ISSUES/133-the-control-planes-schema-is-migrated-at-birth-and-never-again/00-report.md)).
|
||||
- A module crash-looping at start — 338 restarts — was found by reading a container's logs by hand.
|
||||
Nothing on the bus said the mesh's graph had stopped learning.
|
||||
- A run-once step that fails now stops an upgrade by design ([ADR 0133](0133-a-module-owns-its-migrations-and-the-mesh-owns-when-they-run.md)),
|
||||
and the same silence would cover it: the version simply would not appear.
|
||||
|
||||
**And the one thing the control plane does emit is refused by its own account.** Answering a catalogue
|
||||
that asks to catch up, it publishes each recorded build under `mesh.mod.control-plane.event.…` — a
|
||||
module namespace for a module that does not exist. Its own permissions refuse it, so a catalogue that
|
||||
restarts gets nothing and keeps its gap. The control plane has facts to state and nowhere to state
|
||||
them.
|
||||
|
||||
## Decision
|
||||
|
||||
**The mesh emits the deploy half of the pipeline as facts on the bus.** What a machine now runs, and
|
||||
what it refused to run and why. Both are facts about the mesh doing its work, in the same form as every
|
||||
other fact on the bus, so anything that wants them subscribes the way the catalogue subscribes to
|
||||
`built`.
|
||||
|
||||
**The control plane states them, as the holder of the `mesh-controller` seat.** Its facts live under the
|
||||
seat's own namespace, which is where a role's events belong
|
||||
([ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md),
|
||||
[ADR 0129](0129-a-seat-carries-the-protocol-of-its-role.md)) and which survives the control plane being
|
||||
replaced. That is also what gives the catch-up replay a subject it may publish instead of an invented
|
||||
module namespace.
|
||||
|
||||
**Emitted when what a machine runs changes, not on every convergence pass.** A host reconciles
|
||||
continuously and reports each time; a fact per pass would be a fact per minute per machine that says
|
||||
nothing. The report carries the declaration it applied and what changed, so the control plane has what
|
||||
it needs to speak only when there is something to say.
|
||||
|
||||
**A refusal is a fact with a subject in it** — which machine, which resource, and the reason as the host
|
||||
gave it. A refusal that names only the machine is the silence this record is about, one level up.
|
||||
|
||||
**Reports stay where they are.** A node's report remains control traffic that only the control plane
|
||||
reads. The deploy facts are derived from it, which makes them second-hand on purpose: one emitter, one
|
||||
ordering, and no widening of the narrowest account in the mesh.
|
||||
|
||||
## Options considered
|
||||
|
||||
1. **Leave it as it is, and let whatever cares ask the control plane.** Rejected: asking for a fact that
|
||||
already arrives is the shape the mesh removed everywhere else, and nothing can react at the moment a
|
||||
machine changes — which is exactly when a graph, an audit or an operator wants to know.
|
||||
2. **Each node emits its own facts.** Rejected: it widens every host's account to an event namespace, and
|
||||
a host's authority is deliberately the narrowest in the mesh. Its report already reaches the one thing
|
||||
that can speak for it.
|
||||
3. **Widen who may read the control branch.** Rejected: that branch carries what machines say *to* the
|
||||
control plane, enrolment included. Widening its readers widens that too, for an unrelated reason.
|
||||
4. **A registry of deploy hooks** — something registers interest and is called. Rejected: an event is
|
||||
already the mechanism; there is nothing to register, and a callback is an address the mesh spent
|
||||
[issue 102](../04-ISSUES/102-an-address-recorded-at-genesis-or-build-does-not-follow-the-nodes-ports/00-report.md)
|
||||
learning not to keep.
|
||||
5. **Put the facts on the node's own declaration stream.** Rejected: that stream is last-per-subject by
|
||||
design, so a machine away for an hour gets exactly the current declaration and nothing older. A
|
||||
history of what happened cannot live in a stream built to forget.
|
||||
|
||||
## Consequences
|
||||
|
||||
**The audit logger gets the deploy half for nothing**, because it consumes everything.
|
||||
|
||||
**A failure becomes visible where the mesh is watched** rather than where someone happened to be
|
||||
looking. That answers the open question [issue 133](../04-ISSUES/133-the-control-planes-schema-is-migrated-at-birth-and-never-again/00-report.md)
|
||||
left about a record the store refused.
|
||||
|
||||
**The catch-up replay stops being a burst of events.** With the control plane able to state its own
|
||||
facts, replaying history as if it were happening now is a choice rather than the only option — and the
|
||||
better shape is the question the catalogue is actually asking, answered once
|
||||
([design 33](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md)).
|
||||
|
||||
**The facts are second-hand.** The control plane says what a machine reported, so a machine that cannot
|
||||
reach the bus produces no fact at all. Absence is not health, and what a machine was last heard from
|
||||
stays the place that says so.
|
||||
|
||||
**The events stream carries more.** Bounded by emitting on change rather than on every pass, and each
|
||||
fact is small; the stream's own limits remain what keeps it finite.
|
||||
|
||||
## How this is checked
|
||||
|
||||
- **The control plane's grant names exactly the subjects it emits**, derived from its seat like every
|
||||
other principal's, and the composed user list is compared against a golden file — so a fact it cannot
|
||||
publish fails a test rather than a catalogue's replay.
|
||||
- **A convergence that changed nothing emits nothing.** A test with two identical reports and one
|
||||
expected fact, because the failure this guards against is a fact per minute per machine.
|
||||
- **A refusal names its resource.** A test where a host reports a failed resource and the emitted fact
|
||||
carries which one and why, not merely that something went wrong.
|
||||
- **What the mesh emits is what something consumes.** The subject a module declares it consumes derives
|
||||
to the subject the control plane publishes — the same agreement test that already keeps the
|
||||
controller's own subscriptions honest.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0041](0041-events-are-a-relationship.md) — an event is a relationship, not a call
|
||||
- [ADR 0126](0126-a-module-declares-its-own-seats.md) — an event is addressed to its emitter, because the emitter's identity is the meaning
|
||||
- [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md), [ADR 0129](0129-a-seat-carries-the-protocol-of-its-role.md) — a role's events belong to the role
|
||||
- [ADR 0083](0083-one-push-leaves-the-mesh-consistent.md) — a report is held for the store rather than lost
|
||||
- [ADR 0133](0133-a-module-owns-its-migrations-and-the-mesh-owns-when-they-run.md) — the gate whose failure this makes visible
|
||||
- [`03-DESIGN/01-to-be/32-what-a-module-declares.md`](../03-DESIGN/01-to-be/32-what-a-module-declares.md) §6 — the lifecycle, which ends today at a report nobody else may read
|
||||
- Measured 2026-09-28: 45 minutes of builds recorded nowhere with the overview reporting health; a module at 338 restarts found by hand; the control plane's only emitted event refused by its own permissions
|
||||
@@ -0,0 +1,153 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-28
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
supersedes: 0133-a-module-owns-its-migrations-and-the-mesh-owns-when-they-run.md
|
||||
---
|
||||
|
||||
# 135. A module version prepares its state before it runs
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0133](0133-a-module-owns-its-migrations-and-the-mesh-owns-when-they-run.md) settled who runs a
|
||||
module's migrations and when, and it said so in the wrong vocabulary. It put the declaration on a
|
||||
*container* — "a container may declare steps to run before it" — and derived the scope of the work from
|
||||
the *machine*. Both are wrong at the level a module author works at, and the second is wrong on the
|
||||
facts.
|
||||
|
||||
**A container is one resource kind the host applies.** A module has code, state and a version; whether
|
||||
its artifact is an image, a bundle or something later is the mesh's business. The module-facing
|
||||
vocabulary for a module's own code already exists and has nothing to do with a container runtime: a
|
||||
module declares **entrypoints** — this file is my tools, this file is my provisioner — and the mesh runs
|
||||
them. A manifest that says "run this container with these arguments, and here are the volumes and
|
||||
environment again" has an author writing down the machine's business twice.
|
||||
|
||||
**And the scope is not the machine's to decide, because the mesh already decided what a state is.** A
|
||||
consumer is a module *on a machine* (migration 0015, from
|
||||
[issue 022](../04-ISSUES/022-one-credential-per-node-per-provision-not-per-module/00-report.md)):
|
||||
the mesh derives a login per consumer and the provider creates a database owned by exactly that login
|
||||
([ADR 0048](0048-a-provider-creates-the-credential-the-mesh-minted.md)). So a module on three machines is three
|
||||
consumers, three credentials and three databases. There is no shared state for two machines to race over,
|
||||
and ADR 0133's central caveat — that a module's migrations must take a lock because two machines might
|
||||
migrate at once — describes a situation the mesh does not currently produce.
|
||||
|
||||
That correction makes the whole "level" question HAL answered with stages disappear: the scope of
|
||||
preparation is the scope of the state, and the mesh knows it.
|
||||
|
||||
What the earlier record got right and this one keeps: the module owns the work, the mesh owns the moment,
|
||||
the gate is the guarantee, migrations stay forward-only, and none of it can be inferred from inside an
|
||||
artifact. What produced it also stands — the control plane was replaced with a build carrying a migration,
|
||||
nothing applied it, and for three quarters of an hour every build was refused by the store with one line
|
||||
that reached only whoever was waiting on a reply
|
||||
([issue 133](../04-ISSUES/133-the-control-planes-schema-is-migrated-at-birth-and-never-again/00-report.md)).
|
||||
|
||||
## Decision
|
||||
|
||||
**A module version declares an entrypoint that prepares its state.** One name in the manifest, in the
|
||||
same vocabulary as the entrypoints it already declares for its tools and its provisioner. No container,
|
||||
no command line, no environment, no mounts — those are how a machine runs the module's code, and the
|
||||
module already said that once.
|
||||
|
||||
**The mesh runs it as it runs that module's own code, to completion, in the module's own context.** Every
|
||||
binding, credential and setting the module's code would receive, because it *is* the module's code. How a
|
||||
machine does that is the host's business and stays there: for an image artifact it is the step
|
||||
[ADR 0052](0052-a-step-that-runs-once-before-a-container.md) already defines, and a later kind of artifact
|
||||
changes the host, not the manifest.
|
||||
|
||||
**Preparation gates the version.** A version whose preparation did not succeed does not run — anywhere.
|
||||
Since the rollout already sends machines one at a time and stops at the first that does not take a
|
||||
version, a preparation that fails stops the rollout there, leaving every other machine on the version
|
||||
that works.
|
||||
|
||||
**Preparation is scoped to the state, and the mesh derives that scope.** State the mesh provisions is per
|
||||
consumer — a module on a machine — so preparation happens once per consumer. State the module keeps on
|
||||
the machine is per machine, which is the same answer. A module that holds an exclusive seat has one of
|
||||
itself, so its preparation happens once by definition. No level, no election, no cross-node ordering, and
|
||||
no lock obligation invented for a race the mesh does not create.
|
||||
|
||||
**Once per version per state.** A version bump attempts preparation once against each state it has; the
|
||||
module's own runner decides there is nothing to do, which is what a runner with a version table does
|
||||
anyway. A retry after a partial failure runs it again, so the work is the module's to make safe against
|
||||
that — the one obligation no design can remove.
|
||||
|
||||
**Forward-only and additive.** Preparation runs while the previous version is still serving, so a
|
||||
migration that removes or renames what the old code reads breaks the mesh in the window between the two.
|
||||
|
||||
**Declared, never inferred.** The control plane cannot see inside an artifact, so a module that ships
|
||||
migrations and declares no entrypoint is not refusable at registration. It breaks on its first upgrade,
|
||||
and this record says so rather than implying a check that cannot exist.
|
||||
|
||||
## Options considered
|
||||
|
||||
1. **A container declares steps before it** — [ADR 0133](0133-a-module-owns-its-migrations-and-the-mesh-owns-when-they-run.md).
|
||||
Superseded, not because the mechanism is wrong but because the *declaration* is in the wrong place: it
|
||||
makes every module author restate the machine's arrangement, and it ties a module's own lifecycle to
|
||||
one resource kind. The host-side mechanism it named is retained and is now an implementation detail.
|
||||
2. **Each module prepares itself when it starts** — what the catalogue does today. Rejected: a schema
|
||||
failure becomes a crash loop rather than a stop, nothing in the declaration says the module has a
|
||||
state to prepare, and the version serves the moment it starts rather than after the state is right.
|
||||
3. **The mesh applies migrations itself**, with a driver and a version table per store type. Rejected:
|
||||
the mesh would have to know one store from another, hold another module's credentials and reach a
|
||||
machine with them, which [ADR 0005](0005-the-node-host.md) forbids. It is also what forces a stage
|
||||
system: something central has to decide where the work happens.
|
||||
4. **A hook lifecycle** — pre-build, post-build, pre-deploy, post-deploy. Rejected: a declaration is a
|
||||
desired state reconciled forever, so there is no deploy moment to hook. "Pre-deploy" is exactly this
|
||||
record; pre- and post-build are what a recipe and the artifact list already are; "post-deploy" names
|
||||
nothing that happens.
|
||||
5. **A declared level** — once per module, or once per assignment. Rejected: the mesh already knows what a
|
||||
state is, so asking an author to choose is asking them to restate a fact the mesh holds, with a chance
|
||||
of contradicting it.
|
||||
6. **Record a preparation level per module in the store.** Rejected for the reason ADR 0133 gave and this
|
||||
record keeps: gating makes the invariant true by construction, and a level is a second account of the
|
||||
same fact.
|
||||
|
||||
## Consequences
|
||||
|
||||
**An author's whole contract is one line, once.** Write the migration in the module's code, name the
|
||||
entrypoint that runs it, and every later version rolls out as: build, prepare, run — with nothing
|
||||
per-version to remember and nothing about the machine to restate. That is the property this exists for.
|
||||
|
||||
**Three hand-written steps in the catalogue collapse**, and the control plane's own migrate step stops
|
||||
repeating its server's environment and mounts.
|
||||
|
||||
**The catalogue's self-preparation becomes the exception to remove.** One shape, and the mesh's own
|
||||
control plane is not an exception either.
|
||||
|
||||
**A module scaled across machines with one shared state is not expressible**, and this record does not
|
||||
make it so. The mesh gives each consumer its own state; a deliberately shared one is a different
|
||||
provision model, and the place the "once, mesh-wide" question would genuinely return. Named here so it is
|
||||
a decision when it happens rather than a surprise.
|
||||
|
||||
**There is still no readiness-gated step.** Only an action carries `verify`; nothing declares that a
|
||||
service answers, so preparation that must happen *after* something is serving — seeding through its own
|
||||
API — remains unexpressible.
|
||||
|
||||
**Genesis keeps its own action.** At birth there is no control plane to derive anything, which is what
|
||||
[ADR 0067](0067-genesis-is-a-pivot.md) says about that moment.
|
||||
|
||||
## How this is checked
|
||||
|
||||
- **The composition carries the preparation, in the module's own context.** A test on a node's composed
|
||||
declaration: a version declaring a preparation entrypoint is preceded by it, and what it is given
|
||||
equals what the module's own code is given — asserted equal rather than written twice, which is the
|
||||
drift the superseded shape invited.
|
||||
- **A preparation that fails stops the version.** The host does not go past a step that did not complete,
|
||||
and the rollout stops at the first machine that did not take a version. Both are existing behaviours
|
||||
with existing tests; the test for preparation asserts the two together — the machine does not run it,
|
||||
and the machines after it are left alone.
|
||||
- **Once per version per state.** A test that a second convergence of the same version prepares nothing,
|
||||
and that a new version prepares again.
|
||||
- **The mesh's own control plane declares one.** The case that failed on 2026-09-28 is the case the tests
|
||||
cover, rather than a case a comment says is covered.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0133](0133-a-module-owns-its-migrations-and-the-mesh-owns-when-they-run.md) — what this supersedes, and why
|
||||
- [ADR 0052](0052-a-step-that-runs-once-before-a-container.md) — the host-side step that implements it for an image artifact
|
||||
- [ADR 0048](0048-a-provider-creates-the-credential-the-mesh-minted.md), [issue 022](../04-ISSUES/022-one-credential-per-node-per-provision-not-per-module/00-report.md) — a consumer is a module on a machine, which is what makes the scope derivable
|
||||
- [ADR 0018](0018-a-picture-is-read-from-what-runs.md) — a digest is the record that something happened
|
||||
- [ADR 0005](0005-the-node-host.md) — the control plane decides and never touches a machine
|
||||
- [ADR 0134](0134-the-mesh-says-what-it-applied.md) — what makes a failed preparation visible
|
||||
- [issue 133](../04-ISSUES/133-the-control-planes-schema-is-migrated-at-birth-and-never-again/00-report.md) — the failure that produced both records
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-28
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0052-a-step-that-runs-once-before-a-container.md
|
||||
---
|
||||
|
||||
# 136. A step gates its module, not the machine
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0052](0052-a-step-that-runs-once-before-a-container.md) made a run-once container a step the host
|
||||
runs to completion, and gave it the same reach a failed action has: it stops everything the declaration
|
||||
places after it. When the only steps on the mesh were a broker's seed and a forge's admin account, that
|
||||
reach was invisible — the thing after the step was the container the step existed for, in the same
|
||||
module.
|
||||
|
||||
[ADR 0135](0135-a-module-version-prepares-its-state-before-it-runs.md) made a step something the mesh
|
||||
derives for **any** module that prepares its state, and that turns the reach into a fault. A module
|
||||
whose database is briefly unreachable now stops every module declared after it on that machine, for as
|
||||
long as it is unreachable.
|
||||
|
||||
**The host already rejected this for every other shape, and says why in its own loop.** From
|
||||
[issue 011](../04-ISSUES/011-one-broken-module-blocks-every-other/00-report.md):
|
||||
|
||||
> It used to stop at the first one, and that made one broken resource hold the whole machine hostage: a
|
||||
> module declaring a package that does not exist meant every module ordered after it was never applied,
|
||||
> for ever, and the mesh reported "failed" without saying that the rest had not been tried. A machine
|
||||
> with one bad module and nine good ones ran none of the nine.
|
||||
|
||||
Everything is attempted and every failure reported — except an action and a run-once step, kept as the
|
||||
deliberate exceptions. So the mesh has two rules about the same question and the wider one is now
|
||||
reachable by any module that declares a schema.
|
||||
|
||||
**And it deadlocks a case the catalogue already named.** The catalogue migrates its own schema when it
|
||||
starts rather than in a step, and says why in its code: *a schema step that had to reach the provider
|
||||
over the overlay would block the very apply that brings the overlay up*. With a machine-wide gate that
|
||||
is exactly right — the step fails, the apply stops, the overlay module after it is never applied, and
|
||||
the next reconcile is blocked the same way. The module that most obviously wants a step could not have
|
||||
one.
|
||||
|
||||
## Decision
|
||||
|
||||
**A step gates its own module.** A run-once container that does not complete stops the rest of *that
|
||||
module's* resources and nothing else. Every other module on the machine is attempted, as every other
|
||||
shape already is.
|
||||
|
||||
**An action still gates the machine.** Genesis is a row of actions, each making the next possible, and
|
||||
they belong to no module — there is nothing narrower for their reach to be.
|
||||
|
||||
**What was not attempted is reported, not inferred from silence.** A skipped resource appears in the
|
||||
machine's account of the apply as skipped, with the reason, because "not attempted" and "nothing to do"
|
||||
are different answers and only one of them is somebody's to fix.
|
||||
|
||||
**A module is the part of a resource's identity before the first dot**, which is how the mesh composes
|
||||
them. What the mesh declares in its own right — a guard, an opening, the adoption's own resources —
|
||||
belongs to no module, and its gate is therefore the machine's.
|
||||
|
||||
## Options considered
|
||||
|
||||
1. **Leave the reach as it is.** Rejected: it reintroduces, through a mechanism now derived for every
|
||||
module, exactly the fault issue 011 removed. A mesh where one module's unreachable database stops a
|
||||
machine converging is worse than one where that module alone is behind.
|
||||
2. **Make preparation not a gate at all** — run it and carry on. Rejected: then a version serves against
|
||||
a state nobody shaped, which is the whole of what ADR 0135 exists to prevent.
|
||||
3. **Order every module's step before everything else on the machine**, so a gate stops nothing that
|
||||
matters. Rejected: it inverts the order a module needs — its files and directories are declared before
|
||||
its step because the step reads them — and it would still stop later modules.
|
||||
4. **Let a module declare how far its step reaches.** Rejected: the answer is the same for every module,
|
||||
and a field would let one be wrong about it.
|
||||
|
||||
## Consequences
|
||||
|
||||
**The catalogue can move to a step.** The reason it migrates at start — that a step blocks the apply
|
||||
that would make its provider reachable — stops being true: the step fails, that module waits, the
|
||||
overlay comes up, and the next reconcile prepares it. One shape for the whole mesh, which is what
|
||||
ADR 0135 asked for and could not have had.
|
||||
|
||||
**A module can sit behind while the machine is otherwise current.** That is the honest state and it is
|
||||
what the report now says. It also means a preparation that never succeeds is a module that never
|
||||
upgrades, quietly, until somebody reads the report — which is an argument for
|
||||
[ADR 0134](0134-the-mesh-says-what-it-applied.md) rather than against this.
|
||||
|
||||
**A module's resources must be ordered within the module for the gate to mean anything.** They already
|
||||
are: the mesh composes a module's resources in the order its manifest declares them, and its own
|
||||
workload comes after the files it reads.
|
||||
|
||||
## How this is checked
|
||||
|
||||
- **A failed step stops its module and nothing else.** A test with two modules: the one whose step
|
||||
failed does not start its workload, the other starts, and the error still says the failure gated
|
||||
something. It fails against the previous behaviour, which is how it was written.
|
||||
- **An action still stops the machine.** The existing test for a failed action is unchanged, and a step
|
||||
with no module in its identity — which is what genesis carries — takes the same path.
|
||||
- **The report names what was skipped.** Asserted in the same test, because a gate nobody can see is
|
||||
indistinguishable from a module that had nothing to do.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0052](0052-a-step-that-runs-once-before-a-container.md) — the step this narrows
|
||||
- [ADR 0135](0135-a-module-version-prepares-its-state-before-it-runs.md) — what made the reach reachable
|
||||
- [issue 011](../04-ISSUES/011-one-broken-module-blocks-every-other/00-report.md) — the same fault, removed once already
|
||||
- [ADR 0134](0134-the-mesh-says-what-it-applied.md) — how a module left behind becomes visible
|
||||
- mesh-host `internal/apply` — the loop whose own comment argued this case for every other shape
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: superseded
|
||||
date: 2026-09-28
|
||||
deciders: jochen
|
||||
extends: 02-DECISIONS/0100-a-node-in-use-is-adopted-before-it-is-converged.md
|
||||
reconstructed: false
|
||||
superseded-by: 02-DECISIONS/0140-the-filter-constrains-what-arrives-from-outside.md
|
||||
---
|
||||
|
||||
# 137. A machine says which networks it routes
|
||||
|
||||
## Context
|
||||
|
||||
The filter the mesh derives denies forwarding by default, because without a forward chain it says
|
||||
nothing about a container's published port
|
||||
([ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md), [issue 047](../04-ISSUES/047-the-firewall-does-not-cover-published-container-ports/00-report.md)).
|
||||
To keep a machine's own containers working it then allows two ranges: the container runtime's
|
||||
default bridge pool, and the pool its compose files are given. Those two are named in the
|
||||
controller's code, with a comment saying what the gap is:
|
||||
|
||||
> A machine whose runtime is configured with something else needs this to say so — which is a thing
|
||||
> the mesh cannot derive and a reason this list is named here rather than computed.
|
||||
|
||||
**There was no way to say so.** The list was a constant. A machine whose guests live anywhere else
|
||||
was filtered by a rule that looked deliberate and was a guess.
|
||||
|
||||
**Measured, on the day a workstation was converged.** Flipping it cut egress for five of its
|
||||
container networks at once, and for every network its test beds create — the beds allocate a fresh
|
||||
range per run, from a pool neither default covers. Nothing reported a fault. The containers could
|
||||
not reach anything, the machine went on reporting that it had applied what it was told, and the
|
||||
converge preview had said nothing about it either, because the preview lists what *listens* and
|
||||
routing is not a listener.
|
||||
|
||||
**And two questions, not one.** A guest also asks its host for an address and for names. Both arrive
|
||||
at the input chain, where nothing declared them, so denying by default left the guests of a routed
|
||||
network with no address and no resolution — which is not a closed port but a network that does not
|
||||
function, asked for by this machine's own guest.
|
||||
|
||||
**Why the machine cannot simply be read.** A test bed creates its bridge while it runs, between one
|
||||
declaration and the next, so a filter derived from what the machine last reported would be correct
|
||||
only for the networks that already existed when it was composed. A declared range covers the ones
|
||||
that do not exist yet.
|
||||
|
||||
## Decision
|
||||
|
||||
**A machine says which networks it routes for what it hosts, and the filter forwards them.** A
|
||||
node-level fact, beside the node's public domain
|
||||
([ADR 0066](0066-public-routing-is-name-agnostic.md)) and for the same reason: the
|
||||
machine routes them, and the module that loads the filter holds a seat and may be replaced.
|
||||
|
||||
**Added to the runtime's defaults, never replacing them.** A machine that names one range has not
|
||||
stopped hosting whatever was already on the runtime's own pools, and replacing would trade one
|
||||
silent breakage for another.
|
||||
|
||||
**Their guests keep address and name service.** For a network that was named, the input chain admits
|
||||
that network's own DHCP and DNS, and nothing else: everything else a guest might want from its host
|
||||
is a port somebody declares, like every other port on this machine.
|
||||
|
||||
**Said in CIDR form and checked when it is said.** An entry that does not parse is a line nftables
|
||||
refuses, and a refused ruleset is a machine filtering nothing while its unit reports a fault — so
|
||||
the refusal happens where a person can read it, not on the machine.
|
||||
|
||||
**A machine that says nothing is filtered exactly as before.** Every machine already converged is
|
||||
untouched by this.
|
||||
|
||||
## Options considered
|
||||
|
||||
1. **Leave it constant and edit the code per installation.** Rejected: the value is a property of
|
||||
one machine, the code is the whole mesh's, and the two ranges as they stand describe a machine
|
||||
whose runtime was left at its defaults. It is also how this got here.
|
||||
2. **Derive it from what the machine reports.** Rejected as insufficient, not as wrong: it cannot
|
||||
cover a network created between two declarations, which is precisely the case that was broken. It
|
||||
would also make the filter follow whatever appeared on the machine, which is a firewall that
|
||||
widens itself.
|
||||
3. **A per-node setting on the module that loads the filter.** Rejected: the machine routes the
|
||||
networks. The filter module holds a node-scoped seat and is meant to be replaceable, and a
|
||||
replacement must not lose the machine's own truth.
|
||||
4. **Replace the defaults with what is said.** Rejected: see the decision. The first machine to name
|
||||
its bed range would lose its containers.
|
||||
5. **Admit all input from a routed network, not only address and name service.** Rejected: that is
|
||||
every port on the machine open to anything it hosts, which is the derivation abandoned.
|
||||
|
||||
## Consequences
|
||||
|
||||
**The converge preview says what a machine routes**, including when it routes nothing but the
|
||||
defaults, with the command that changes it. The preview's own sentence about traffic it cannot
|
||||
preview stays, because a tunnel and the found firewall's NAT are still not previewable.
|
||||
|
||||
**A machine whose guests are already broken by an earlier flip is fixed by saying its networks and
|
||||
pushing**, with no flip to undo.
|
||||
|
||||
**The list is one more thing that can be wrong and stale.** A range removed from the machine and
|
||||
left here keeps forwarding for a network that no longer exists, which admits nothing, because there
|
||||
is no guest on it to admit. That is the safe direction of being out of date.
|
||||
|
||||
## How this is checked
|
||||
|
||||
- **What a machine says it routes is forwarded, and its guests keep address and name service.** A
|
||||
test renders a ruleset for a machine that names one range and asserts both chains, per chain body
|
||||
so a line in the wrong chain cannot pass it. It fails against the previous behaviour, which is how
|
||||
it was written.
|
||||
- **The runtime's own defaults survive naming a range.** Asserted in the same test.
|
||||
- **A machine that names nothing renders byte-identically to one that names nil**, so every machine
|
||||
already behind this filter is untouched.
|
||||
- **Each family is matched in its own syntax.** A test with one v4 and one v6 network asserts
|
||||
`ip saddr` and `ip6 saddr`, because one set holding both is a syntax error and a ruleset that does
|
||||
not load is a machine filtering nothing.
|
||||
- **An entry that is not a network is refused where it is said**, by the parse in the setter.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md) — the derived filter this completes
|
||||
- [ADR 0066](0066-public-routing-is-name-agnostic.md) — the precedent for a node-level fact
|
||||
- [issue 047](../04-ISSUES/047-the-firewall-does-not-cover-published-container-ports/00-report.md) — why there is a forward chain at all
|
||||
- [issue 137](../04-ISSUES/137-converging-a-machine-cut-off-its-own-guests/00-report.md) — the measurement that produced this
|
||||
- mesh-controller `internal/catalogue/filtering.go` — the constant whose own comment named this gap
|
||||
@@ -0,0 +1,205 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-28
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md
|
||||
---
|
||||
|
||||
# 138. An assignment binds an endpoint and says how far it reaches
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0045](0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md) settled that a machine's
|
||||
packet filter is derived from what its modules declare they listen on, and that the `from` of a
|
||||
listen "is the whole of public-versus-internal". That was true of the packet filter, and it turned
|
||||
out to be true of nothing else.
|
||||
|
||||
Reachability is now settled three times, in three places, by three mechanisms that cannot disagree
|
||||
out loud ([issue 140](../04-ISSUES/140-an-endpoints-reach-is-not-declared/00-report.md)):
|
||||
|
||||
- **The filter** reads a listen's source, and a per-node setting may override it. That setting has
|
||||
exactly one caller in the control plane — the function that builds the node's rules.
|
||||
- **The names** come from a route contribution, which names a label and a port and says nothing
|
||||
about reach. The reverse proxy composes a **public** name and an **internal** name for every route
|
||||
it is given, because it can.
|
||||
- **The certificate authority** follows from which names exist. Measured on the control-node: an
|
||||
identity provider carries a public certificate valid 90 days and an internal one valid 24 hours and
|
||||
renewed daily. No assignment asked for either.
|
||||
|
||||
So *this endpoint must not be public* cannot be written. It is therefore enforced by nothing, while a
|
||||
public certificate for that very name is obtained automatically — the fault
|
||||
[how-we-build.md](../00-META/how-we-build.md) names, an unenforced rule being indistinguishable from
|
||||
a wrong one, with the additional cost that the wrong thing is done eagerly.
|
||||
|
||||
And a port that is not routed cannot be spoken about at all beyond the filter. The forge serves git
|
||||
over ssh; that endpoint has no name, no certificate and no way to be called public except a key only
|
||||
the filter reads.
|
||||
|
||||
**Two per-node settings already exist and are half of this.** One gives a module's declared port a
|
||||
machine port. One overrides a declared port's source. They key on port numbers, so nothing ties a
|
||||
port to the route that serves it: a route contribution names a port too, and the two are equal only
|
||||
by coincidence.
|
||||
|
||||
**Where this belongs is already decided.** [ADR 0046](0046-a-module-configuration-is-its-assignments-not-its-manifest.md)
|
||||
says a module's configuration is its assignments. Whether the forge answers git-over-ssh from the
|
||||
public internet is a fact about one installation and one machine, not a property of the software —
|
||||
and [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md) already refuses an
|
||||
installation's decisions in a definition.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Leave reach in the manifest, as `from` today.** Rejected: it is an installation's decision
|
||||
written into the definition, and it cannot differ between two machines running the same module —
|
||||
which is exactly the case the forge presents.
|
||||
2. **Extend the existing source override to the names and the certificate, without naming
|
||||
endpoints.** Rejected: it keys on a port number. A module's route contribution names a port as
|
||||
well, and nothing says the two are the same thing, so one statement cannot be made to reach all
|
||||
three mechanisms. Naming the endpoint is what makes that possible.
|
||||
3. **Derive reach from whether the node has a public domain recorded.** Rejected: that is a property
|
||||
of the machine, and two endpoints on one machine differ — a database and a web front end on the
|
||||
same host.
|
||||
4. **A fourth reach for "public name, internal authority"** — a name that resolves publicly and must
|
||||
not appear in a public issuance log, obtained by DNS-01. Deferred, not rejected: it is a real case
|
||||
and it is a question about which challenge an authority uses, not about how far an endpoint
|
||||
reaches. Left to the certificate work as an open question.
|
||||
5. **Make the manifest silent on reach and require every assignment to state it.** Rejected for the
|
||||
transition: every endpoint reachable today would close until an assignment named it, which is a
|
||||
flag day across the whole catalogue.
|
||||
|
||||
## Decision
|
||||
|
||||
**A module declares named endpoints.** An endpoint is one port the module serves, with a name the
|
||||
module chooses, its protocol, and what it is for. A route contribution **names the endpoint it
|
||||
routes** rather than repeating a port number. The manifest says what the module serves and what it
|
||||
would serve it to by default; it does not say what this installation does with it.
|
||||
|
||||
**An assignment binds each endpoint and says how far it reaches.** Per node: the machine port the
|
||||
endpoint is published on, and its **reach** — one of `internal`, `public` or `both`. An assignment
|
||||
that states nothing keeps the manifest's default, so no machine changes until an assignment says so.
|
||||
|
||||
**Reach means all three mechanisms at once, and is the only thing that decides them.**
|
||||
|
||||
- `internal` — the filter opens the machine port to the private network; the proxy serves the
|
||||
internal name and not the public one; the certificate comes from the mesh's own authority.
|
||||
- `public` — the filter opens it to anywhere; the proxy serves the public name; the certificate
|
||||
comes from the public authority.
|
||||
- `both` — both names, each from its own authority, and the filter opens to anywhere.
|
||||
|
||||
**An endpoint that is not routed is reached but never named.** An endpoint with no route contribution
|
||||
yields filter rules and nothing else: no name is composed and no certificate is requested. Git over
|
||||
ssh is that case, and it is the case the model could not express.
|
||||
|
||||
**The authority stops being chosen by which names happen to exist.** The proxy composes the names the
|
||||
assignments asked for, and asks each name's own authority for it. A name nobody asked for is not
|
||||
composed, so it is not certified.
|
||||
|
||||
**The two existing settings are this, completed.** The per-node port mapping becomes the endpoint's
|
||||
binding. The per-node source override becomes its reach, widened from the filter alone to the names
|
||||
and the certificate as well.
|
||||
|
||||
## Progressive insight — 2026-09-29, from building it
|
||||
|
||||
**Reach does not mean the same thing to the filter for an endpoint the proxy serves.** The decision
|
||||
above says `internal` means "the filter opens the machine port to the private network" and `public`
|
||||
means "the filter opens it to anywhere". For a routed endpoint the second half is wrong, and
|
||||
[ADR 0045](0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md) already said so before this
|
||||
record was written: *a public service is exposed through the proxy, not by opening its own port* — it
|
||||
listens `from: mesh`, only the proxy reaches it, and it is exposed by name.
|
||||
|
||||
Found by trying to express one real module, not by review. Its routed name must be public, because
|
||||
browsers post to it; its machine-side port must not be, because that port serves the dashboard in
|
||||
cleartext. Under one value driving both, saying "public" would have reopened a port an operator had
|
||||
just closed. Measured the same evening: that module's routed name answered from the internet over TLS
|
||||
while its machine-side port was refused from the same place. The port is not the path.
|
||||
|
||||
So the reach of a **routed** endpoint asks for names, and its port keeps what the manifest said. The
|
||||
reach of an **unrouted** endpoint — git over ssh, a mail port, the bus — governs the port, because
|
||||
there is no name and the port is the only way in. That is the same split this record already draws in
|
||||
*an endpoint that is not routed is reached but never named*; what it got wrong was carrying the filter
|
||||
across it.
|
||||
|
||||
This corrects a fact, not the decision: one statement per endpoint, three things derived from it and
|
||||
none of them deciding on its own, all stand. The table in the decision should be read with the filter
|
||||
column applying to an unrouted endpoint.
|
||||
|
||||
## Progressive insight — 2026-10-02, from issue 191
|
||||
|
||||
**For a routed endpoint, "the proxy serves the internal name" has to mean "serves it to the private
|
||||
network", and only the proxy can make it mean that.** The decision says `internal` means the proxy
|
||||
serves the internal name and not the public one. It does not say to whom, and the proxy answered
|
||||
every name it routes to any request that carried it, on the same listeners as its public names. A
|
||||
name being internal kept nobody out: a request from the internet only had to send it. While every
|
||||
routed endpoint also had a public name, nothing showed it. Once an endpoint could be internal alone
|
||||
([issue 191](../04-ISSUES/191-a-route-with-only-an-internal-name-is-dropped/00-report.md)), serving
|
||||
its name to everyone would have published exactly what `internal` was chosen to keep private.
|
||||
|
||||
The earlier insight above says the port is not the path for a routed endpoint. This is its other
|
||||
half: the proxy is the path, so the proxy is where `internal` is enforced. It serves an internal name
|
||||
only to the machines of the mesh and to the machine itself
|
||||
([ADR 0144](0144-anything-on-a-machine-may-call-anything-on-it.md)). Who the mesh is, it is told,
|
||||
not left to work out: its membership carries the same list of machine addresses the filter's "from the
|
||||
mesh" is rendered from ([ADR 0167](0167-a-membership-carries-what-its-module-receives-and-who-the-mesh-is.md)).
|
||||
To anyone else, the name is answered as one never routed, in the handshake and in the request, and not
|
||||
listed among the names it serves. This holds for the internal name of a `both` endpoint too, whose
|
||||
outsiders have its public name.
|
||||
|
||||
The decision, the options and the consequences stand: one statement per endpoint, three things
|
||||
derived from it. Checked in the proxy's own tests: an internal-only name is served to a machine the
|
||||
membership names and to loopback, and refused, unlisted and uncertified for any other request; until
|
||||
the mesh is issued, it is served to the machine alone.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **A manifest gains endpoint names, and a route contribution names an endpoint instead of a port.**
|
||||
Every routed module's manifest changes. The word ships one release before any manifest uses it, and
|
||||
reaches the build machine and the control plane first.
|
||||
- **One derived value is read by three things** — the filter's rules, the proxy's contributions, the
|
||||
certificate request — so they can no longer disagree, and a disagreement becomes a refusal at the
|
||||
assignment rather than a surprise on a machine.
|
||||
- **A name that must not be public becomes writable, and therefore checkable.** It also gives
|
||||
[issue 129](../04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/00-report.md) a
|
||||
declared answer to read: which endpoints are internal is what says whose root must be installed
|
||||
where.
|
||||
- **[Issue 139](../04-ISSUES/139-an-internal-route-name-resolves-to-the-consumers-node/00-report.md)
|
||||
becomes answerable**: the endpoint's assignment names the machine that serves it, which is the fact
|
||||
the internal name should be composed from.
|
||||
- **Reach becomes reportable.** The mesh can say, per endpoint, where it is reachable from and which
|
||||
authority holds its certificate — neither of which `status` can say today.
|
||||
- **This narrows [ADR 0045](0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md).** Its
|
||||
decision stands: the firewall is derived and host-applied, not a provider. What no longer holds is
|
||||
that a listen's `from` is the whole of public-versus-internal; it is the filter's share of a
|
||||
statement that also governs names and certificates.
|
||||
- **What got harder:** every endpoint needs a name, including a module that serves exactly one port
|
||||
and had no reason to name it. And an installation that wants a module public must now say so on the
|
||||
assignment rather than inheriting it from the definition, which is more to say and the reason it is
|
||||
right.
|
||||
|
||||
## How it is checked
|
||||
|
||||
- **One module, two endpoints, different reach.** A module declaring an internal endpoint and a
|
||||
public one renders a filter opening one to the private network and one to anywhere, asserted per
|
||||
chain body so a rule in the wrong chain cannot pass.
|
||||
- **The names follow the reach.** The same module's routed endpoint composes the internal name only
|
||||
when internal, the public name only when public, and both when both — and a certificate is
|
||||
requested from the matching authority for each name composed and for no other. This fails against
|
||||
the previous behaviour, where both names and both certificates are always composed, which is how
|
||||
it is written.
|
||||
- **An unrouted endpoint is filtered and never named.** Asserted for an endpoint with reach and no
|
||||
route contribution: rules rendered, no contribution, no certificate request.
|
||||
- **An assignment naming an endpoint the module does not declare is refused where it is said**, as is
|
||||
a reach that is not one of the three — before it reaches a machine, because a ruleset that does not
|
||||
load is a machine filtering nothing.
|
||||
- **An assignment that states nothing renders byte-identically to today**, so every machine already
|
||||
converged is untouched until its assignment says otherwise.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0045](0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md) — narrowed here
|
||||
- [ADR 0046](0046-a-module-configuration-is-its-assignments-not-its-manifest.md) — where reach belongs
|
||||
- [ADR 0066](0066-public-routing-is-name-agnostic.md) — the public name this composes
|
||||
- [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md) — why reach is not a definition's
|
||||
- [issue 140](../04-ISSUES/140-an-endpoints-reach-is-not-declared/00-report.md) — the measurement
|
||||
- [issue 139](../04-ISSUES/139-an-internal-route-name-resolves-to-the-consumers-node/00-report.md),
|
||||
[issue 129](../04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/00-report.md)
|
||||
@@ -0,0 +1,137 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: superseded
|
||||
date: 2026-09-28
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0137-a-machine-says-which-networks-it-routes.md
|
||||
superseded-by: 02-DECISIONS/0140-the-filter-constrains-what-arrives-from-outside.md
|
||||
---
|
||||
|
||||
# 139. A network is forwarded because a module declared it
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0137](0137-a-machine-says-which-networks-it-routes.md), decided the same week, gave a machine a
|
||||
way to say which networks it routes for its guests. It was written because the derived filter's
|
||||
forward chain allowed two ranges named as constants in the control plane's source — the container
|
||||
runtime's bridge pool, and part of the pool its compose files are given — with a comment admitting
|
||||
the gap: *a machine whose runtime is configured with something else needs this to say so, which is a
|
||||
thing the mesh cannot derive.*
|
||||
|
||||
**It can be derived, and from the right place.** Measured on the last machine still to be converged
|
||||
([issue 141](../04-ISSUES/141-the-forward-chain-does-not-follow-the-modules/00-report.md)): twenty-one
|
||||
container networks, nine inside the runtime's bridge pool, twelve in the other private range, and six
|
||||
of those outside the constant's lower bound — so the flip would have cut their guests off exactly as
|
||||
it did on the workstation that produced 0137.
|
||||
|
||||
Naming a range to cover the six is what 0137 provides for, and it is the wrong instrument. Of those
|
||||
six networks, **four are networks the mesh's own modules declare**, present as network resources in
|
||||
the node's plan and created by the host because a module asked for them. **Two are the predecessor's
|
||||
leftovers** — compose networks of services the mesh does not run. Any range wide enough to keep the
|
||||
four forwards the two as well: a firewall widened by hand to protect networks that should not exist.
|
||||
|
||||
The mesh already knows which of the twenty-one are its own, because it made them.
|
||||
|
||||
**And the node's configuration is meant to follow the modules assigned to it.** That is the mesh's
|
||||
founding shape — the machine runs modules, and its files, its filter and its accounts are composed
|
||||
from what runs there ([ADR 0005](0005-the-node-host.md),
|
||||
[ADR 0010](0010-delivery.md),
|
||||
[ADR 0045](0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md)). The forward chain is the
|
||||
one derived thing that consults a constant and a list a person types.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep 0137 as it stands** — two constants plus a named list. Rejected: the list is written in
|
||||
addresses, and addresses are what the runtime allocates, so the only entry safe enough to keep a
|
||||
machine working is wider than the truth. It cannot distinguish a network the mesh made from one
|
||||
left behind, which is the distinction that decides whether forwarding it is correct.
|
||||
2. **Derive it from what the machine reports.** Still rejected, on 0137's own grounds: a test bed
|
||||
creates its bridge between one declaration and the next, and a filter that follows whatever
|
||||
appeared on a machine is a firewall that widens itself. **This decision is not that** — see below.
|
||||
3. **Have the control plane allocate each module network's range from a pool it owns,** so it can
|
||||
render the address itself. Rejected: more machinery for no gain. The runtime already allocates and
|
||||
the host already knows, and taking allocation over means the mesh owning an address space it has no
|
||||
other reason to own.
|
||||
4. **Have each module declare its network's range.** Rejected by
|
||||
[ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md): a definition names no address,
|
||||
and the same definition runs on machines whose runtimes have allocated differently.
|
||||
|
||||
## Decision
|
||||
|
||||
**A network is forwarded because a module declared it.** Per node, the forward chain forwards the
|
||||
networks of the modules assigned there, and by default nothing else. A module unassigned stops being
|
||||
forwarded at the next reconcile.
|
||||
|
||||
**The host resolves a declared network to its addresses.** A network resource carries a name; the
|
||||
runtime allocates the subnet when the network is created. So the control plane declares *forward the
|
||||
networks these modules asked for* and the host — which made them, and already resolves a container by
|
||||
its name — renders the addresses. [ADR 0005](0005-the-node-host.md) holds: the host applies, it does
|
||||
not decide.
|
||||
|
||||
**Deriving from the declaration is not deriving from the machine.** Both of 0137's objections fall
|
||||
away. The set is known before the network exists, because a module declared it, so a network created
|
||||
between two declarations is already in the one that asked for it. And it cannot widen itself: a
|
||||
network nobody declared is never forwarded, however it appeared on the machine.
|
||||
|
||||
**The runtime's own default bridge is forwarded, from what the runtime reports.** Containers that name
|
||||
no module network attach to it, and it belongs to the runtime rather than to any module — so the host
|
||||
renders it from what the runtime says, not from a range named in the control plane. The constants go.
|
||||
|
||||
**What a machine says is for guests no module declares.** A test bed is not a module and its range is
|
||||
not a module's; that is the case 0137's mechanism is for, and it keeps it — added to the derived set,
|
||||
never replacing it, as 0137 decided. Narrowed to that, it is named for it.
|
||||
|
||||
**Their guests keep address and name service**, per declared network, unchanged from
|
||||
[ADR 0137](0137-a-machine-says-which-networks-it-routes.md): the input chain admits that network's own
|
||||
DHCP and DNS and nothing else.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The two constants are removed**, and with them the class of fault that a machine's guests depend
|
||||
on a range that describes some other machine.
|
||||
- **This is a behaviour change, not a refactor.** On the machine measured, the derived set and the
|
||||
constant do not cover the same ground — that is the whole reason for the record. A machine whose
|
||||
module networks happen to fall inside the old ranges renders the same rules.
|
||||
- **A range that exists only to keep a leftover alive becomes visible as such**, because it will not
|
||||
be in the derived set and has to be said out loud to survive.
|
||||
- **`node networks` narrows** to guests no module declares, and the preview says which of a machine's
|
||||
networks are the mesh's and which are not, so the difference is readable before a flip rather than
|
||||
after.
|
||||
- **A module's declaration gains nothing.** It already declares its network; what changes is that the
|
||||
filter reads it.
|
||||
- **What got harder:** the host renders part of the forward chain from what it created, so the
|
||||
control plane no longer holds the whole rule set as text. The rule the mesh states is the set of
|
||||
networks; the addresses are the machine's.
|
||||
|
||||
## How it is checked
|
||||
|
||||
- **Only declared networks are forwarded.** A node with two modules that declare networks renders
|
||||
forward rules for exactly those two, and none for a third network present on the machine that no
|
||||
module declared. This fails against the previous behaviour, which forwards by range and cannot tell
|
||||
them apart, and that is how it is written.
|
||||
- **Unassigning a module removes its network's rule** at the next reconcile, asserted on the rendered
|
||||
chain rather than on the intent.
|
||||
- **Guests of a declared network keep address and name service**, asserted per chain body so a line in
|
||||
the wrong chain cannot pass — carried from 0137.
|
||||
- **The runtime's own default bridge comes from the runtime**, asserted by rendering for a runtime
|
||||
whose default bridge is somewhere other than the range the constant named.
|
||||
- **A machine that names a range for guests no module declares still gets it**, added to the derived
|
||||
set and not replacing it.
|
||||
- **Each family is matched in its own syntax**, carried from 0137: one set holding both is a syntax
|
||||
error, and a ruleset that does not load is a machine filtering nothing while its unit reports a
|
||||
fault.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0137](0137-a-machine-says-which-networks-it-routes.md) — narrowed here; its mechanism keeps the
|
||||
case it is right for
|
||||
- [ADR 0005](0005-the-node-host.md) — the host applies; the addresses are the machine's
|
||||
- [ADR 0045](0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md) — the filter is derived from
|
||||
what runs there
|
||||
- [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md) — why a module does not name its
|
||||
range
|
||||
- [issue 141](../04-ISSUES/141-the-forward-chain-does-not-follow-the-modules/00-report.md) — the
|
||||
measurement
|
||||
- [issue 137](../04-ISSUES/137-converging-a-machine-cut-off-its-own-guests/00-report.md) — the
|
||||
breakage that produced 0137
|
||||
@@ -0,0 +1,146 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-28
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md
|
||||
supersedes:
|
||||
- 02-DECISIONS/0137-a-machine-says-which-networks-it-routes.md
|
||||
- 02-DECISIONS/0139-a-network-is-forwarded-because-a-module-declared-it.md
|
||||
---
|
||||
|
||||
# 140. The filter constrains what arrives from outside, and says nothing about a machine's own guests
|
||||
|
||||
## Context
|
||||
|
||||
The filter the mesh derives blocks traffic passing *through* a machine unless something allows it,
|
||||
because a container's published port is traffic passing through rather than traffic arriving at the
|
||||
machine itself ([ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md),
|
||||
[issue 047](../04-ISSUES/047-the-firewall-does-not-cover-published-container-ports/00-report.md)).
|
||||
Having blocked all of it, the filter then had to let the machine's own containers reach outward again.
|
||||
It does that by listing the address ranges those containers sit on.
|
||||
|
||||
As rendered on a converged workstation today:
|
||||
|
||||
```
|
||||
policy drop
|
||||
ct state established,related accept
|
||||
ip saddr 172.16.0.0/12 accept
|
||||
ip saddr 192.168.128.0/17 accept
|
||||
ip saddr 10.0.0.0/8 accept
|
||||
ip saddr 192.168.16.0/20 accept
|
||||
... four more
|
||||
```
|
||||
|
||||
Two of those ranges were constants in the control plane's source. The rest were typed by the operator
|
||||
after [ADR 0137](0137-a-machine-says-which-networks-it-routes.md), which existed to make the typing
|
||||
possible, because converging that workstation had cut every one of its containers off from the
|
||||
internet and nothing reported a fault
|
||||
([issue 137](../04-ISSUES/137-converging-a-machine-cut-off-its-own-guests/00-report.md)).
|
||||
|
||||
**The list is the mistake, not its contents.** Every attempt to make it correct fails the same way.
|
||||
A constant describes one machine. A typed range goes stale, and cannot tell a network the mesh made
|
||||
from one a predecessor left behind — measured on the control-node, where six such ranges fall outside
|
||||
the constants and two of the six belong to services the mesh does not run
|
||||
([issue 141](../04-ISSUES/141-the-forward-chain-does-not-follow-the-modules/00-report.md)).
|
||||
[ADR 0139](0139-a-network-is-forwarded-because-a-module-declared-it.md) tried to generate the same
|
||||
list from the modules and put half the rule set on the machine to do it. Three records, one list, and
|
||||
the list should not exist.
|
||||
|
||||
**Because the mesh has no policy about a container reaching outward.** What the filter is for is
|
||||
stated in [ADR 0045](0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md): which port is open,
|
||||
and to whom. That is about what arrives. A container of this machine's own opening a connection to
|
||||
something else is not a port being opened to anybody, and enumerating the addresses it might do so
|
||||
from is bookkeeping about the machine's internal plumbing, which the mesh neither owns nor can know.
|
||||
|
||||
**The system being replaced never had this fault, and its rule says why.** The chain still protecting
|
||||
the control-node applies only to traffic arriving on that machine's outward link, and leaves
|
||||
everything else alone. The mesh's filter dropped that distinction and replaced it with a list of
|
||||
addresses.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep the list and generate it better** — from the modules' declared networks, or from what the
|
||||
machine reports. Rejected: [ADR 0139](0139-a-network-is-forwarded-because-a-module-declared-it.md)
|
||||
is that, and it puts part of the rule set on the machine, which makes the rule set partly the
|
||||
machine's and the derivation advisory.
|
||||
2. **Name the guest links instead of their addresses, and allow only those.** Rejected as more than is
|
||||
needed: it fails in the safe direction, but it is still a list that has to keep up with the
|
||||
machine, and the thing it protects against — a container reaching outward — is not a thing the mesh
|
||||
has a position on.
|
||||
3. **Do not block traffic passing through at all.** Rejected: that is
|
||||
[issue 047](../04-ISSUES/047-the-firewall-does-not-cover-published-container-ports/00-report.md),
|
||||
where a published port was reachable from anywhere because no rule mentioned it.
|
||||
4. **Constrain what arrives from outside, and nothing else.** Adopted.
|
||||
|
||||
## Decision
|
||||
|
||||
**The filter constrains traffic arriving from outside the machine, and says nothing about traffic that
|
||||
did not.** Traffic passing through the machine is allowed unless it arrived on one of the machine's
|
||||
outward links, in which case it is allowed only where a declared endpoint's reach admits it
|
||||
([ADR 0138](0138-an-assignment-binds-an-endpoint-and-says-how-far-it-reaches.md)). A container of this
|
||||
machine's own reaching anywhere is not filtered, because the mesh has no position on it.
|
||||
|
||||
**A machine says which of its links face outside.** One node-level fact, reported by the machine the
|
||||
way it already reports the kind of firewall it found and the tunnel it carries — not a setting, not a
|
||||
list of addresses, and not something anybody types. It does not change when a module is added or
|
||||
removed, which is what separates it from the list it replaces.
|
||||
|
||||
**A machine that has reported no outward link is sent no filter.** Rendering a rule around a link
|
||||
whose name is not known produces a rule set that does not load, which is a machine filtering nothing
|
||||
while its unit reports success. The refusal happens in the control plane, where a person reads it, and
|
||||
the machine keeps the filter it already has.
|
||||
|
||||
**No addresses of the machine's own networks appear in the filter.** The two constants are removed and
|
||||
`node networks` is removed with them, along with everything any machine was told to say through it.
|
||||
Ports continue to follow the modules exactly as before: a module assigned to a machine opens the port
|
||||
its assignment says it reaches on, and nothing about a network is said anywhere.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **Three records collapse into one rule.** 0137 and 0139 are superseded. What 0137 was right about —
|
||||
that converging a machine had silently cut off its own containers, and that nothing previewed it — is
|
||||
answered by removing the cause rather than by giving the operator a way to compensate for it.
|
||||
- **Every machine already converged loses its declared ranges and keeps working**, because the traffic
|
||||
those ranges allowed is now allowed by not having arrived from outside. The workstation's five ranges
|
||||
and the laptop's one are deleted rather than migrated.
|
||||
- **A machine's test beds stop being a special case.** A bed's network is created while the machine
|
||||
runs and was the case no list could cover; it is now covered by not being mentioned.
|
||||
- **A new fact travels in the report**, and the control plane refuses to compose a filter without it,
|
||||
so the order of the roll-out matters: the machines report before the control plane depends on it.
|
||||
- **A machine with more than one outward link says so**, and a machine that acquires one while the mesh
|
||||
is not looking is treated as internal until its next report. That window is the cost of this shape;
|
||||
it is bounded by the report interval, and it exists on machines whose outward link changes, which
|
||||
are the machines with nothing published to the outside.
|
||||
- **What got harder:** nothing in the declaration, and one more thing a machine must be able to work
|
||||
out about itself. A machine that cannot say which link faces outside cannot be given a filter.
|
||||
|
||||
## How it is checked
|
||||
|
||||
- **A machine's own container reaches outward with no network named anywhere.** A bed converges a
|
||||
machine carrying containers on several networks, none of them mentioned in any setting, and each
|
||||
reaches out afterwards. This fails against the previous behaviour, where the same flip cut them off,
|
||||
and that is how it is written.
|
||||
- **A port declared reachable from outside is reachable; one that is not, is not.** Probed from off the
|
||||
machine's private network, for a published port and for an undeclared one, before and after the flip.
|
||||
- **A network created after the filter was composed needs no new filter.** A network is made on the
|
||||
machine after its last declaration and a container on it reaches out, with nothing re-sent.
|
||||
- **No address of a machine's own networks appears in a rendered filter**, asserted on the text so a
|
||||
range cannot creep back in.
|
||||
- **A machine that reports no outward link is sent no filter, and the refusal names it** — asserted in
|
||||
the control plane, and that the machine's existing filter is left alone.
|
||||
- **A machine reporting two outward links has both constrained**, asserted per chain body so a rule
|
||||
covering one and not the other cannot pass.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0045](0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md) — what the filter is for
|
||||
- [ADR 0138](0138-an-assignment-binds-an-endpoint-and-says-how-far-it-reaches.md) — what admits traffic
|
||||
arriving from outside
|
||||
- [ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md) — why traffic passing through is
|
||||
filtered at all
|
||||
- [ADR 0137](0137-a-machine-says-which-networks-it-routes.md),
|
||||
[ADR 0139](0139-a-network-is-forwarded-because-a-module-declared-it.md) — superseded here
|
||||
- [issue 137](../04-ISSUES/137-converging-a-machine-cut-off-its-own-guests/00-report.md),
|
||||
[issue 141](../04-ISSUES/141-the-forward-chain-does-not-follow-the-modules/00-report.md)
|
||||
@@ -0,0 +1,171 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-29
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0005-the-node-host.md
|
||||
---
|
||||
|
||||
# 141. The host delivers its own successor, and versions live side by side
|
||||
|
||||
## Context
|
||||
|
||||
[Issue 142](../04-ISSUES/142-the-host-is-the-one-thing-the-mesh-does-not-deliver/00-report.md). A
|
||||
merge builds every changed module and the control plane — which is itself a module — and the result
|
||||
reaches the machines running it with nobody asking. The host is the exception: it is not a build
|
||||
target, no declaration delivers it, and every machine in this mesh runs a byte-identical binary that
|
||||
somebody built on a workstation and copied out.
|
||||
|
||||
The half that *recovers* from a bad host exists. `internal/upgrade` can tell that the executable this
|
||||
process started from was replaced on disk, and it records which version last completed a reconcile.
|
||||
The launcher counts consecutive failed starts, calls a rollback at the limit, and treats a clean exit
|
||||
as the host standing aside so that the next loop runs whatever is on disk now. That supervision is
|
||||
complete and correct.
|
||||
|
||||
Two things make it dead code:
|
||||
|
||||
- **`Replaced()` is called by nothing but its own tests.** Nothing tells the running host that a
|
||||
successor is waiting.
|
||||
- **The rollback resolves a version through the machine's package manager** — `pacman -U` from the
|
||||
package cache. No machine here has the host installed as a package, so the recovery cannot run on
|
||||
any of them; and being written in one package manager's terms, it cannot run on two of the three
|
||||
operating systems the host is built for — [ADR 0005](0005-the-node-host.md) builds one binary per
|
||||
operating system, pinned at link time.
|
||||
|
||||
**The record already points at the answer.** What is kept is a *version*, not a path. Keeping a
|
||||
version is only useful to something that can choose between versions present on the machine, which is
|
||||
what the package manager was being asked to do. The versions can simply be on disk.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Deliver the host as a package, as the rollback assumes.** Rejected: it needs a package built and
|
||||
a repository trusted per operating system, three of each, and the existing `package` resource
|
||||
asserts presence and deliberately never a version — "version is the package manager's business and
|
||||
the mesh does not hold a second opinion about it" — so it cannot ask for a particular host anyway.
|
||||
Heaviest of the three and the only one that is different on every machine.
|
||||
2. **Write the new binary over the running one.** Rejected on a fact: a running executable cannot be
|
||||
truncated, and `archive` opens what it unpacks with `O_TRUNC`. It could be made to write and
|
||||
rename, which is better hygiene and worth doing for its own sake, but it buys nothing here that
|
||||
option 3 does not, and it leaves rollback with nowhere to go back to.
|
||||
3. **Versions side by side; the newest retires the old.** Adopted.
|
||||
|
||||
## Decision
|
||||
|
||||
**A host version is delivered as an archive into a directory named for it, and never over a running
|
||||
one.** The declaration names it like any other archive — fetched by digest, the digest checked before
|
||||
anything is unpacked. Nothing new travels, no new resource kind, and no change to how archives are
|
||||
applied, because the path being written is not the path being executed.
|
||||
|
||||
**The launcher starts the most recently delivered version.** That is what "the newest" means: the
|
||||
version whose directory arrived last. It reads no pointer and follows no link — the mesh creates no
|
||||
links ([ADR 0012](0012-the-mesh-creates-no-symlinks.md)) — and the version is in the path, so nothing
|
||||
has to be told what is running.
|
||||
|
||||
**The running host stands aside for a successor, and only between reconciles.** Finding a newer
|
||||
version delivered, it finishes the reconcile it is in and exits cleanly. The launcher already reads a
|
||||
clean exit as exactly this and starts what is on disk now. A host that stood aside mid-apply is the
|
||||
half-configured machine this project exists to prevent, so the check happens at the boundary and
|
||||
nowhere else.
|
||||
|
||||
**A version that completes a reconcile records itself, and retires what came before it.** The
|
||||
known-good record is written as it is today. Then versions older than the one before the running one
|
||||
are removed: the running version and its predecessor are kept, which is exactly what a rollback
|
||||
needs, and nothing else accumulates.
|
||||
|
||||
**Rollback starts the previous version instead of reinstalling a package.** At the failure limit the
|
||||
launcher pins the known-good version and starts that, once. The second failure is still a different
|
||||
diagnosis — the previously working version does not run either, so it is the machine and not the
|
||||
binary — and the halt is unchanged. No package manager, no package cache, and the same script on every
|
||||
operating system.
|
||||
|
||||
**A machine says which host version it is running,** on the report it already sends, beside the other
|
||||
facts it states about itself. Without it nothing can say a machine is behind, so "every machine
|
||||
current with its source" cannot include the host.
|
||||
|
||||
## Progressive insight — 2026-09-29, the same day
|
||||
|
||||
**The delivery is not "nothing new", and this record said it was.** The decision above stands and is
|
||||
built: versions side by side, the newest runs, the running host stands aside between reconciles, a
|
||||
completed reconcile retires what is older than the predecessor, rollback picks a directory. What was
|
||||
wrong was a claim about how a version reaches a machine. The paragraph on delivery said the
|
||||
declaration "names it like any other archive… nothing new travels, no new resource kind"; the second
|
||||
half is true and the first is not, because two things the delivery needs do not exist:
|
||||
|
||||
- **Nothing can compile it.** A `bundle` artifact is compiled by a closed list of toolchains —
|
||||
typescript and python — whose own comment says adding a language is a decision, because a language
|
||||
used by *modules* needs an SDK carrying the broker client, the event envelope and tool serving. The
|
||||
host uses none of that: it is what applies modules, not one of them. So the obligation that list
|
||||
warns about attaches to a module written in a language, not to the language being buildable, and
|
||||
the control plane — also written in Go — is built as an image from a Dockerfile rather than through
|
||||
a toolchain at all.
|
||||
- **A version cannot reach the path.** An `archive` resource names a fixed path in the manifest, and
|
||||
nothing interpolates the built version into it, so nothing can ask for
|
||||
`…/versions/<version>/`.
|
||||
|
||||
Neither changes what was decided, which options were weighed, or any consequence: the shape is
|
||||
unaffected and the host half is merged and tested. What it changes is the cost, which this record
|
||||
understated as none. The remaining work is a way to build the host and a way to name a version in a
|
||||
path, and until both exist nothing delivers a version and every machine takes the fallback — which is
|
||||
what every machine does today.
|
||||
|
||||
> **Progressive insight — 2026-09-30. Both of those exist now.** The paragraph above named two missing
|
||||
> things and they are built: a Go toolchain, based on a new `mesh-tools-go` module so the compiler is
|
||||
> named and not pinned, and `${version}` in any value of a resource that uses an archive or a bundle.
|
||||
> The mesh compiles its own host and publishes it to its own registry, measured — a statically linked
|
||||
> stripped binary, fetched back out and run. **The cost was larger again than this note said**: three
|
||||
> more things in the path assumed one language or one shape, and a fourth was in the base image.
|
||||
> The account is [issue 142](../04-ISSUES/142-the-host-is-the-one-thing-the-mesh-does-not-deliver/01-progress.md).
|
||||
>
|
||||
> The version in a path is the artifact's **digest**, not the commit this note's own wording would
|
||||
> suggest. Two builds of one commit are meant to be the same bytes, so a content-addressed version
|
||||
> means an unchanged build keeps the path it had; a commit-named one would move for an identical binary
|
||||
> and recreate everything reading it.
|
||||
>
|
||||
> **Still nothing delivers a version to a machine.** The host is a module and builds, and declares no
|
||||
> resources, so the bundle sits in the registry and no machine is asked to take it. That is the next
|
||||
> piece, and the decision above is unchanged by any of this.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The host becomes a build target and a module** — a module whose resource is the next host, applied
|
||||
by the host that is running. The bootstrap is not circular because the two are different versions in
|
||||
different directories.
|
||||
- **Rollback becomes usable on every machine**, having been usable on none. It also stops being
|
||||
written in one operating system's terms.
|
||||
- **One copy by hand remains, once.** The first host that understands versioned directories cannot be
|
||||
fetched by a host that does not. That copy is the last, and it is the honest cost of the change
|
||||
rather than a step in the design.
|
||||
- **Two versions occupy disk instead of one.** About nine megabytes. The predecessor is the price of a
|
||||
rollback that does not depend on a cache somebody else may clean.
|
||||
- **What got harder:** a host must now be able to find its own successor and to judge when it is safe
|
||||
to stand aside. Both are between reconciles, which is the only moment the host is not mid-change.
|
||||
- **A machine that is never told a newer version keeps running what it has**, indefinitely and
|
||||
visibly, because its report says which version that is.
|
||||
|
||||
## How it is checked
|
||||
|
||||
- **A delivered version is run, and the old one is not.** A bed delivers a second version to a machine
|
||||
running the first; the host exits between reconciles, the launcher starts the new one, and the
|
||||
machine reports the new version. This fails against the previous behaviour, where nothing notices a
|
||||
delivered version at all.
|
||||
- **It stands aside between reconciles and never inside one.** Asserted by delivering a version while
|
||||
an apply is in flight: the apply completes, and the exit follows it.
|
||||
- **A version that will not start is rolled back to its predecessor, once**, and the second failure
|
||||
halts with the machine named rather than the binary — asserted with no package manager involved.
|
||||
- **A completed reconcile retires what is older than the predecessor**, and never the predecessor
|
||||
itself, because that is what a rollback needs. Asserted on the directory afterwards.
|
||||
- **The report names the running version**, asserted end to end rather than on the function that reads
|
||||
it, since the point is that the control plane can tell a machine is behind.
|
||||
- **The launcher picks the newest delivered version** with no pointer file and no link, asserted by
|
||||
delivering two and checking which runs.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0005](0005-the-node-host.md) — the host, and what its supervision is for
|
||||
- [ADR 0010](0010-delivery.md) — a declaration is owned resources; this adds no kind to it
|
||||
- [ADR 0012](0012-the-mesh-creates-no-symlinks.md) — why the version is in the path
|
||||
- [ADR 0005](0005-the-node-host.md), *it is built per operating system* — why a rollback written in
|
||||
one package manager's terms was wrong for two of three
|
||||
- [issue 142](../04-ISSUES/142-the-host-is-the-one-thing-the-mesh-does-not-deliver/00-report.md) — the
|
||||
measurement
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-09-29
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0141-the-host-delivers-its-own-successor.md
|
||||
---
|
||||
|
||||
# 142. The mesh delivers its own components as binaries, not as container images
|
||||
|
||||
## Context
|
||||
|
||||
Measured on the control-node, 2026-09-29:
|
||||
|
||||
| what | how it runs | publishes |
|
||||
|---|---|---|
|
||||
| host | a binary on the machine | — |
|
||||
| controller, catalogue, builder, vault | containers | nothing |
|
||||
| store, registry, broker | containers | ports |
|
||||
|
||||
**The mesh's own software is delivered two ways, and the difference is not a property of the
|
||||
software.** The host and the controller are both written in the same language, both the mesh's own,
|
||||
both doing the mesh's own work. One is an image fetched from a registry. The other is a file somebody
|
||||
copied to four machines, owned by no package, built by nothing
|
||||
([issue 142](../04-ISSUES/142-the-host-is-the-one-thing-the-mesh-does-not-deliver/00-report.md)).
|
||||
|
||||
**The reason is not a judgement about either, it is that images are the only delivery that works.**
|
||||
There is no way to put a binary on a machine. The host is hand-copied because of that, and the
|
||||
controller is an image because of that. Neither was chosen on its merits.
|
||||
|
||||
What it costs, all of it measured rather than argued:
|
||||
|
||||
- **Genesis must raise a container runtime before the control plane can exist.** The bundle carries
|
||||
three images and one of them is the controller, *"in the bundle for the same reason they are: there
|
||||
is nothing to fetch it with yet"*
|
||||
([design 07](../03-DESIGN/01-to-be/07-the-foundation.md)). So the hardest moment in the mesh's life
|
||||
has a prerequisite that the thing being started does not need.
|
||||
- **Updating the control plane depends on the control plane.** Its image is fetched from the registry,
|
||||
which is a container the controller manages.
|
||||
- **A change to the host cannot be rolled out at all.** Every machine here runs a byte-identical
|
||||
hand-copied binary. A change merged yesterday reached none of them.
|
||||
- **Compiling the language the mesh is written in is not a capability of the builder.** The bundle
|
||||
toolchains are typescript — real, with a registered base module — and python, which is named in the
|
||||
list and absent from the catalogue. The controller is built as an image from a Dockerfile, which is
|
||||
the per-repository incantation the bundle toolchain exists to abolish
|
||||
([design 18](../03-DESIGN/01-to-be/18-building-a-module.md)).
|
||||
|
||||
The half that *receives* a binary safely is already built and tested
|
||||
([ADR 0141](0141-the-host-delivers-its-own-successor.md)): versions side by side in directories named
|
||||
for them, the newest run, the running one standing aside between reconciles, retirement keeping the
|
||||
predecessor, and a rollback that chooses a directory. What is missing is everything that puts one
|
||||
there.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Leave it as it is.** Rejected: it is not a design, it is the reach of one mechanism. And it is
|
||||
what makes a host change undeliverable.
|
||||
2. **Containerise the host too**, so everything is delivered one way. Rejected: the host is what
|
||||
starts the container runtime and what applies containers. A host in a container is the bootstrap
|
||||
problem made total, and the machine would have no way back from a bad one.
|
||||
3. **Deliver the mesh's components as operating-system packages.** Rejected for the reason
|
||||
[ADR 0141](0141-the-host-delivers-its-own-successor.md) rejected it for the host: a package and a
|
||||
trusted repository per operating system, three of each, and the `package` resource asserts presence
|
||||
and deliberately never a version.
|
||||
4. **Binaries for the mesh's own components, containers for third-party software.** Adopted.
|
||||
|
||||
## Decision
|
||||
|
||||
**The mesh's own components are delivered as binaries on the machine.** The host, the controller, the
|
||||
catalogue, the builder, the vault — the software this project writes. They are delivered by the
|
||||
mechanism [ADR 0141](0141-the-host-delivers-its-own-successor.md) built: an archive, fetched by
|
||||
digest, unpacked into a directory named for its version, with the running one standing aside between
|
||||
reconciles and a rollback that chooses the predecessor.
|
||||
|
||||
**Third-party software stays a container.** The store, the registry, the broker. They are somebody
|
||||
else's build, they are already adopted as modules
|
||||
([ADR 0078](0078-the-store-and-broker-are-modules.md)), and an image is the right way to carry
|
||||
somebody else's software. **The container runtime remains required** — modules use it — so this
|
||||
removes a dependency from the control plane, not from the machine.
|
||||
|
||||
**The builder compiles the languages the mesh is written in.** A toolchain for Go, with a base module
|
||||
providing the compiler, exactly as typescript has. The obligation the toolchain list warns about — an
|
||||
SDK carrying the broker client, the envelope and tool serving — attaches to a *module* written in a
|
||||
language, not to the language being compilable. None of these components is a module in that sense;
|
||||
the host is what applies modules.
|
||||
|
||||
**An artifact says what it targets.** A compiled binary is per operating system, pinned at link time
|
||||
([ADR 0005](0005-the-node-host.md)), and a toolchain deliberately takes nothing from the module,
|
||||
because anything a module could override there it would be writing a Dockerfile to override. So the
|
||||
target is a property of the artifact rather than of the recipe, and one artifact declared per target
|
||||
is one build each.
|
||||
|
||||
**A component's version comes from where it sits, not from its linker.** It is unpacked into a
|
||||
directory named for its version, so it can read its own version from its path. The stamp goes, and
|
||||
with it the need for a build to know what it will be called.
|
||||
|
||||
**Genesis carries a binary reference where it carried an image reference.** The principle does not
|
||||
change — the bundle names a thing by digest and the host fetches it, pinned because nothing can
|
||||
resolve a version when no mesh exists — and the container runtime stops being a prerequisite for the
|
||||
control plane. It stays a prerequisite for the store and the broker, which is where it belongs.
|
||||
|
||||
**The order is staged, and each step stands alone.** Compiling Go; an artifact naming its target;
|
||||
delivering a binary; the host as the first component delivered; the controller, catalogue, builder and
|
||||
vault out of their containers; genesis last. Genesis is last for the reason it is always last: it
|
||||
matters for a machine nobody has yet, and every earlier step is provable on a mesh that exists.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **One delivery for the mesh's own software**, so a change to the host ships the way a change to the
|
||||
controller does, and neither is copied by hand.
|
||||
- **The control plane stops depending on a container runtime and on its own registry.** Both remain on
|
||||
the machine for other reasons; neither gates the control plane's own life any more.
|
||||
- **`Replaced()`, the known-good record and the launcher's rollback stop being dead code.** They were
|
||||
written for this and have been called by nothing but their tests.
|
||||
- **Four more components gain a rollback they do not have.** Today a bad controller image is recovered
|
||||
by an operator; under this it is recovered the way a bad host is.
|
||||
- **Two versions of each component occupy disk.** Around nine megabytes each. The predecessor is what a
|
||||
rollback needs.
|
||||
- **Genesis gets smaller, not larger.** One fewer image to carry and one fewer runtime to raise before
|
||||
the control plane.
|
||||
- **This does not make the components smaller or simpler.** They are the same programs; what changes is
|
||||
how they arrive. A reader expecting the containers to have been hiding complexity will not find any.
|
||||
- **What got harder:** the builder gains a language, artifacts gain a target, and the mesh gains a
|
||||
second kind of thing it must deliver correctly — one where getting it wrong takes the control plane
|
||||
down rather than a module. That is why the host is first: it is the component whose recovery is
|
||||
already built and tested.
|
||||
|
||||
## How it is checked
|
||||
|
||||
- **A component is delivered and runs, with nothing copied by hand.** A bed builds the host from its
|
||||
repository, delivers it to a machine running an older one, and the machine reports the new version.
|
||||
This fails today at the first step, because nothing builds it.
|
||||
- **Each target is built once and only the matching one is delivered.** Asserted by declaring an
|
||||
artifact per operating system and checking that a machine is offered the one it can run — a host
|
||||
built for another is what ADR 0005's link-time pin exists to refuse.
|
||||
- **A component reads its version from its path**, asserted by unpacking the same bytes into two
|
||||
differently named directories and seeing each report its own.
|
||||
- **A bad component is rolled back without an operator**, for the host first: a version that will not
|
||||
start is replaced by its predecessor once, and the second failure halts naming the machine.
|
||||
- **The control plane comes up with no registry reachable**, which is the dependency this removes —
|
||||
asserted by raising it with the registry stopped.
|
||||
- **Genesis raises a control plane with no container runtime running**, and raises the store and the
|
||||
broker afterwards. Last, and on a machine with nothing on it.
|
||||
- **A published port count that does not change.** The mesh's own components publish nothing today, so
|
||||
moving them out of containers must not open anything — asserted on the machine's reachable set before
|
||||
and after, which the converge preview already reads.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0141](0141-the-host-delivers-its-own-successor.md) — the receiving half, already built
|
||||
- [ADR 0005](0005-the-node-host.md) — the host, its supervision, and one binary per operating system
|
||||
- [ADR 0078](0078-the-store-and-broker-are-modules.md) — why third-party software stays a container
|
||||
- [ADR 0006](0006-the-substrate-and-the-control-plane.md) — what genesis must raise, and in what order
|
||||
- [issue 142](../04-ISSUES/142-the-host-is-the-one-thing-the-mesh-does-not-deliver/00-report.md) — the
|
||||
measurement that started this
|
||||
- [design 07](../03-DESIGN/01-to-be/07-the-foundation.md) — the bundle's three images, one of them the
|
||||
controller
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: superseded
|
||||
date: 2026-09-29
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0010-delivery.md
|
||||
superseded-by: 02-DECISIONS/0144-anything-on-a-machine-may-call-anything-on-it.md
|
||||
---
|
||||
|
||||
# 143. A consumer verifies the grant it is given
|
||||
|
||||
## Context
|
||||
|
||||
A **grant** is what the mesh writes on a consumer's machine so it can reach a provider. The real one
|
||||
the forge receives for its database, as it arrives:
|
||||
|
||||
```
|
||||
provision postgres-database
|
||||
at <the provider's machine, by name>
|
||||
port the machine port the provider is published on
|
||||
as the role the provider created for this consumer
|
||||
```
|
||||
|
||||
with the credential sealed in a separate file. Four facts and a password, and they are the whole
|
||||
mechanism by which anything in the mesh reaches anything else.
|
||||
|
||||
**The mesh asserts that claim and never finds out whether it is true.**
|
||||
[Issue 145](../04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md):
|
||||
converging a machine dropped the path from a container to a port on its own machine, and for eleven
|
||||
hours the mesh answered *all doing what they were told, all heard from, every module current with its
|
||||
source* while a web application logged, six thousand times:
|
||||
|
||||
```
|
||||
connection to server at "<the machine>" (10.10.0.1), port 6852 failed: timeout expired
|
||||
```
|
||||
|
||||
Every check the mesh makes passed, because every check it makes is about the relationship between the
|
||||
mesh and a machine: the declaration was applied, the digest matched, every container named was running.
|
||||
None of them asks whether a consumer can reach what it requires — though the mesh composed the grant
|
||||
and therefore knows the consumer, the machine, the address, the port and the credential.
|
||||
|
||||
**And where the check runs decides whether it catches anything.** The rule in force admitted the
|
||||
machines' own addresses on the private network. A dial from the *machine* to its own address carries
|
||||
exactly such a source address, so a check run by the host on its own behalf would have matched that rule
|
||||
and passed — while every container on the machine was refused. This is inference from the rule that was
|
||||
loaded, not a measurement: the fault was found and fixed before anyone thought to dial from the host.
|
||||
It is enough to decide the question, because a check whose position differs from the consumer's is
|
||||
testing something nobody asked about.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **The control plane dials each provision.** Rejected, and it is the tempting one because the control
|
||||
plane holds every fact. It sits on the provider's machine for most provisions here and reaches the
|
||||
address by a path no consumer uses; in the measured outage it would have passed throughout.
|
||||
2. **The host dials on the consumer's behalf, from the machine.** Rejected for the reason above: the
|
||||
machine's network position is not the consumer's, and the one outage this exists to catch is exactly
|
||||
a difference between them.
|
||||
3. **Ask the module.** Rejected: a module is arbitrary software that the mesh does not write. Some could
|
||||
report on their provisions and most cannot, and a check that covers the modules that opted in tells
|
||||
nobody anything about the rest.
|
||||
4. **Read the module's logs.** Rejected: the failure was in a log the whole time, and reading a module's
|
||||
logs makes the mesh depend on the wording of software it does not control.
|
||||
5. **The consumer verifies it, from its own network position.** Adopted.
|
||||
|
||||
## Decision
|
||||
|
||||
**A consumer verifies each grant it is given, from its own network position.** After a reconcile has
|
||||
applied a grant, the machine opens a connection to the address and port that grant names, from inside
|
||||
the consumer's own network namespace — the same position the consumer's software dials from, which is
|
||||
the only position that answers the question the grant asks.
|
||||
|
||||
**It is a connection, not a conversation.** Whether the port accepts a connection is what a grant
|
||||
claims; whether the credential is right, the role exists or the schema is current is the provider's to
|
||||
answer and the consumer's to discover. A check that spoke each provision's protocol would be a second
|
||||
implementation of every provision, and would fail for reasons that are not the mesh's.
|
||||
|
||||
**One failure is not news.** A provider restarting is ordinary, and so is a consumer between containers.
|
||||
A grant is reported unreachable only after it has failed on **consecutive** reconciles, and the count is
|
||||
what the machine reports rather than the last attempt — so a reader can tell "it was briefly away" from
|
||||
"it has never worked".
|
||||
|
||||
**A grant that cannot be checked is said to be unchecked, never assumed good.** A consumer that is not
|
||||
running has no network position to dial from; that is not a broken grant and must not read as one. It is
|
||||
also not a verified grant, and the two are different sentences.
|
||||
|
||||
**What it costs to be wrong is the constraint on all of it.** A check that reports a working provision
|
||||
broken trains a reader to ignore the report, which is worse than having none — the fault this
|
||||
repository keeps finding, one level up. So the threshold is consecutive failures, the check is the
|
||||
cheapest thing that answers the question, and an unknown is reported as unknown.
|
||||
|
||||
**The mesh says it where it says everything else.** A machine's report carries its unreachable grants,
|
||||
and `status` names them beside what is out of date — so "every module current with its source" stops
|
||||
being the whole of what the mesh will tell you about a machine whose modules cannot reach each other.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The mesh can be wrong out loud.** It has been able to assert a grant and not check it; now a grant
|
||||
that does not work is a thing the mesh says, and the eleven hours of issue 145 become minutes.
|
||||
- **The host gains the ability to act from a container's network position**, which it has not needed
|
||||
before. That is a real capability and the only one this needs.
|
||||
- **A machine reports something that is not about the declaration.** Everything it reports today is
|
||||
what it applied and what it holds; this is the first thing it says about whether what it applied
|
||||
works.
|
||||
- **A provision with no port is not checked**, because there is nothing to dial. Several are files and
|
||||
secrets, and saying "checked" about those would be the appearance of verification that this record
|
||||
exists to remove.
|
||||
- **What got harder:** a reconcile does more than apply. Every grant adds a connection attempt on a
|
||||
cadence, which is cheap individually and worth naming: a machine with many consumers dials once per
|
||||
grant per reconcile.
|
||||
|
||||
## How it is checked
|
||||
|
||||
- **The outage is caught.** A bed drops the path from a consumer's network position to a provider's
|
||||
port while leaving the machine's own path to it open — the exact shape of issue 145 — and the grant
|
||||
reads unreachable. This fails against the previous behaviour, where nothing reported anything, and
|
||||
against a check run from the machine, which passes while the consumer cannot reach it.
|
||||
- **A restarting provider is not an outage.** One failed reconcile reports nothing; the count rises and
|
||||
falls, and the grant reads reachable again without anybody acting.
|
||||
- **A consumer that is not running reads unchecked, not broken**, asserted separately from the
|
||||
unreachable case because they are different sentences.
|
||||
- **A provision with no port is not claimed to be checked.**
|
||||
- **The report carries the count, not the last attempt**, so "briefly away" and "never worked" are
|
||||
distinguishable by a reader who sees only the report.
|
||||
- **`status` names an unreachable grant**, asserted on the output, since a check nothing surfaces is
|
||||
the same as no check.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0010](0010-delivery.md) — the declaration is owned resources; a grant is one of them
|
||||
- [ADR 0009](0009-modules-and-the-graph.md) — what a provision and a consumer are
|
||||
- [issue 145](../04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md)
|
||||
— the eleven hours
|
||||
- [issue 136](../04-ISSUES/136-a-module-may-name-a-program-the-machine-does-not-have/00-report.md) — the
|
||||
same distance between a declaration and a machine, one level down
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-29
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md
|
||||
supersedes: 02-DECISIONS/0143-a-consumer-verifies-the-grant-it-is-given.md
|
||||
---
|
||||
|
||||
# 144. Anything on a machine may call anything on it, and that is the whole of "local"
|
||||
|
||||
## Context
|
||||
|
||||
Everything in the mesh should be able to call:
|
||||
|
||||
- what runs on the same machine;
|
||||
- another machine's service over the private network, if that service is exposed there;
|
||||
- another machine's service over the public network, if it is exposed there.
|
||||
|
||||
Three cases. The filter had two of them.
|
||||
|
||||
**The first was broken and the break was invisible.** A service exposed to the private network rendered
|
||||
as the machines' own addresses on it. A caller on the machine carries such an address; a caller inside
|
||||
one of that machine's containers carries a bridge address and matched nothing. Measured:
|
||||
|
||||
```
|
||||
the machine: local 10.10.0.1 dev lo src 10.10.0.1
|
||||
a container: 10.10.0.1 via 172.17.0.1 dev eth0 src 172.17.0.8
|
||||
```
|
||||
|
||||
Same destination, same machine, two source addresses. The rule named the first and silently refused the
|
||||
second, so a module reaching its database on its own machine's name timed out for eleven hours
|
||||
([issue 145](../04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md)).
|
||||
|
||||
**The second case works, and by accident.** A caller on another machine reaches the private network over
|
||||
the tunnel, and arrives carrying that machine's own address — so the rule matches. It would not have
|
||||
matched the caller's own address either; the tunnel rewrites it. That two of three cases worked is why
|
||||
this looked correct.
|
||||
|
||||
**[ADR 0143](0143-a-consumer-verifies-the-grant-it-is-given.md) answered the wrong question.** Written
|
||||
hours earlier, it proposed that a consumer verify each grant it is given by opening a connection from
|
||||
its own network position — and it went to some length about *which* position, because whether a caller
|
||||
sat in a container changed the answer. That difference was the bug. A verification mechanism would have
|
||||
reported this outage sooner and would not have prevented it, and the machinery it needed existed only
|
||||
because the rule was wrong. The remedy for a configuration error is the correct configuration.
|
||||
|
||||
**And a module is not a container.** A module is software that delivers one or more services, and it may
|
||||
do that as a container, an installed package with a unit, a binary, or files something else reads. Of 72
|
||||
modules in the catalogue, 61 happen to use a container and 11 do not — among them the resolver, the ssh
|
||||
daemon and the intrusion-prevention module. A rule that reasons about containers describes most of the
|
||||
mesh and not the mesh.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **A line per service admitting the machine's own callers.** Rejected: it is what was written first,
|
||||
and it only ever covers the services somebody remembered to think about. It also states, service by
|
||||
service, a thing that is true of the machine.
|
||||
2. **Verify each grant from the consumer's position** ([ADR 0143](0143-a-consumer-verifies-the-grant-it-is-given.md)).
|
||||
Rejected as a remedy: it observes the fault rather than removing it, and the question it agonised over
|
||||
— which network position — exists only while the fault does.
|
||||
3. **Enumerate the addresses a machine's callers may have.** Rejected for the reason no address is named
|
||||
anywhere in this filter any more ([ADR 0140](0140-the-filter-constrains-what-arrives-from-outside.md)):
|
||||
a range describes one machine and goes stale in silence.
|
||||
4. **Local is not filtered, stated once.** Adopted.
|
||||
|
||||
## Decision
|
||||
|
||||
**Anything on a machine may call anything on that machine, and the filter says so once.** Not per
|
||||
service, not per port, and not by naming who the callers are: traffic that did not arrive from outside
|
||||
the machine and did not arrive over the private network is the machine's own, and is admitted. It is
|
||||
asked by the link the traffic arrived on, because that is a fact about the machine rather than a list
|
||||
that describes one.
|
||||
|
||||
**Local is not a boundary this mesh draws.** Whether a caller is a container, a unit, or the operator's
|
||||
shell changes nothing, because the thing being decided is "is this the same machine" and the answer does
|
||||
not depend on the form the caller takes.
|
||||
|
||||
**The other two cases are unchanged and are now legible beside it.** A service exposed to the private
|
||||
network admits the machines on it; a service exposed publicly admits anything. Three cases, three lines,
|
||||
and a reader can see all three at once.
|
||||
|
||||
**[ADR 0143](0143-a-consumer-verifies-the-grant-it-is-given.md) is superseded and nothing replaces it.**
|
||||
Whether the mesh should check that a grant works is a real question — it reported this machine healthy
|
||||
for eleven hours — but it is a question about what the mesh can say, not about what it should do, and it
|
||||
must stand on its own rather than as the remedy for a rule that was wrong. It is not built.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The three things everything should be able to call are three lines**, and the first is one line
|
||||
rather than one per service, so a service added tomorrow is reachable locally without anybody
|
||||
remembering to say so.
|
||||
- **A form of module stops mattering to the filter.** The 11 modules that are not containers were never
|
||||
affected by this bug and were never the reason it was hard to see; they are the reason the rule should
|
||||
never have mentioned containers.
|
||||
- **The mesh still cannot say when a grant stops working.** That is the live gap, recorded in issue 145
|
||||
and no longer pretending to have an answer.
|
||||
- **What got harder:** nothing. This removes a line per service and replaces it with one.
|
||||
|
||||
## How it is checked
|
||||
|
||||
- **A caller on the machine reaches a service on it, in the input chain**, asserted on that chain's own
|
||||
body — because the forward chain carries the same line in the same words, and an assertion on the
|
||||
whole rendered file passed with the input chain's copy deleted. That is what
|
||||
[ADR 0137](0137-a-machine-says-which-networks-it-routes.md)'s tests already say to do.
|
||||
- **It is one rule, not one per service.** Asserted by rendering two services of different reach and
|
||||
refusing a per-port local line.
|
||||
- **The three reaches render as three lines**, asserted together, so the whole of what the filter says
|
||||
about who may call what is one test.
|
||||
- **The measured case:** from a container on the machine, a service exposed to the private network on
|
||||
that machine answers. This is the outage, and it fails against the rule this replaces.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0045](0045-a-machine-firewall-is-the-sum-of-what-it-listens-on.md) — the filter is the sum
|
||||
of what its modules listen on
|
||||
- [ADR 0140](0140-the-filter-constrains-what-arrives-from-outside.md) — why no address is named
|
||||
- [ADR 0138](0138-an-assignment-binds-an-endpoint-and-says-how-far-it-reaches.md) — internal and public,
|
||||
the other two cases
|
||||
- [ADR 0143](0143-a-consumer-verifies-the-grant-it-is-given.md) — superseded here
|
||||
- [issue 145](../04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md)
|
||||
@@ -0,0 +1,120 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: superseded
|
||||
date: 2026-09-29
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0144-anything-on-a-machine-may-call-anything-on-it.md
|
||||
superseded-by: 02-DECISIONS/0146-connectivity-is-checked-by-name-per-hosting-form.md
|
||||
---
|
||||
|
||||
# 145. A module checks what the mesh claims is reachable, and it checks itself
|
||||
|
||||
## Context
|
||||
|
||||
The mesh asserts three things are callable ([ADR 0144](0144-anything-on-a-machine-may-call-anything-on-it.md)):
|
||||
what runs on the same machine, another machine's service exposed to the private network, and another
|
||||
machine's service exposed publicly. It has never checked any of them.
|
||||
|
||||
[Issue 145](../04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md):
|
||||
the first of the three was broken for eleven hours and the mesh answered *all heard from, every module
|
||||
current with its source* throughout. Every check it makes is about the relationship between the mesh and
|
||||
a machine — applied, current, containers running — and none about whether anything can reach anything.
|
||||
|
||||
**A first answer was drafted and withdrawn.** [ADR 0143](0143-a-consumer-verifies-the-grant-it-is-given.md)
|
||||
put the check inside the host, verifying each grant from the consumer's network position. It was
|
||||
superseded because the difference it worked so hard to reproduce — whether a caller sat in a container —
|
||||
was the bug itself. What survives from it is the part that was right: a check run from the wrong place
|
||||
proves nothing, and the mesh's own reports are not evidence about the network.
|
||||
|
||||
**The mesh already has the shape for this and it is a module.** A module can declare a container that
|
||||
runs on a cadence ([ADR 0053](0053-a-step-that-runs-on-a-schedule.md), and three modules already use
|
||||
`*/5 * * * *`), can be given the mesh's roster as a rendered fact — every machine's name, address and
|
||||
this node's own identity, the same mechanism the resolver and the operator's ssh configuration use — and
|
||||
can emit what it found on the bus. Nothing new is needed to build this except the module.
|
||||
|
||||
**What it must not check is the trap.** The obvious probe target is ssh: present on every machine, never
|
||||
closed by design. Dialling it would have passed throughout the outage, because ssh is admitted
|
||||
unconditionally and the thing that broke was a service exposed to the private network. A checker whose
|
||||
probe is unconditionally open measures the one path that cannot fail, which is the failure this whole
|
||||
sequence keeps producing — a check that reads as verification and verifies nothing.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **The host verifies each grant** ([ADR 0143](0143-a-consumer-verifies-the-grant-it-is-given.md)).
|
||||
Superseded. It needed the host to act from another network position, which is machinery that exists
|
||||
only while local calls are filtered wrongly.
|
||||
2. **The control plane dials every node.** Rejected: it sits on one machine and reaches the others by a
|
||||
path no ordinary caller uses. It would have passed throughout the outage.
|
||||
3. **Probe an existing service.** Rejected for the target problem above: the services guaranteed on every
|
||||
machine are the ones that are never closed, so they cannot fail the way the mesh fails.
|
||||
4. **A module on every machine that serves its own probe and dials the others'.** Adopted.
|
||||
|
||||
## Decision
|
||||
|
||||
**A module runs on every machine, serves an endpoint of its own, and dials every other machine's.** The
|
||||
probe is the module's own endpoint, declared reachable over the private network — so the thing being
|
||||
dialled is admitted by exactly the rule that governs every other internally-exposed service, and fails
|
||||
when that rule is wrong. A second endpoint, declared public, does the same for the public path where a
|
||||
machine has one.
|
||||
|
||||
**It checks the three cases the mesh claims, by name:**
|
||||
|
||||
- its **own machine**, by dialling its own machine's address — the case that broke, and the only one that
|
||||
distinguishes a caller on the machine from a caller in one of its containers;
|
||||
- **each other machine over the private network**;
|
||||
- **each machine's public path**, where one is recorded.
|
||||
|
||||
**It resolves before it dials, and says which failed.** A name that does not resolve and a port that does
|
||||
not answer are different faults with different owners, and a checker that reports one sentence for both
|
||||
sends a reader to the wrong place.
|
||||
|
||||
**It runs where the callers run.** The module's own code in its own container, on the cadence the mesh
|
||||
already has, from the same position as every other module on that machine. It is not the host and not the
|
||||
control plane, and that is the whole point.
|
||||
|
||||
**It says what it found and nothing else.** It emits results; it repairs nothing, opens nothing and holds
|
||||
no credential beyond its own. A checker that fixes things is a second control plane.
|
||||
|
||||
**One failure is not a fault.** A machine rebooting is ordinary. A path is reported broken after it has
|
||||
failed on consecutive runs, and the count travels with the result so a reader can tell "briefly away"
|
||||
from "never worked" — the one thing [ADR 0143](0143-a-consumer-verifies-the-grant-it-is-given.md) got
|
||||
right and worth keeping.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The mesh gains the ability to be wrong out loud about the network.** Eleven hours becomes two runs.
|
||||
- **It is a module, so it is assigned, built, pushed and reported on like everything else** — no new host
|
||||
capability, no new vocabulary, nothing in the control plane that has to know about checking.
|
||||
- **Its own endpoint is the instrument.** That is what makes it able to fail; it also means the checker
|
||||
must be assigned to a machine before that machine can be checked, and a machine without it is
|
||||
unchecked rather than healthy.
|
||||
- **It cannot check what it cannot be told.** The roster gives it machines; it does not give it every
|
||||
module's endpoints, so this checks the paths the mesh claims and not every grant in the mesh. That is
|
||||
the honest scope of a first one, and the difference is worth saying rather than growing quietly.
|
||||
- **What got harder:** one more module on every machine, and a module whose whole purpose is to fail
|
||||
visibly when something else is wrong. Its own failures will be read as the mesh's, which is the cost of
|
||||
an instrument.
|
||||
|
||||
## How it is checked
|
||||
|
||||
- **It catches the measured outage.** A bed closes the path from a container to a service exposed to the
|
||||
private network on its own machine — issue 145's shape — and the checker reports its own machine
|
||||
unreachable while every other path still reads reachable. This fails against a probe on a port that is
|
||||
never closed, which is the wrong target this record exists to name.
|
||||
- **A machine rebooting is not a fault**: one failed run reports nothing, the count rises and falls.
|
||||
- **A name that does not resolve is reported as that**, not as a port that did not answer.
|
||||
- **It reports and does not act**: asserted by giving it a broken path and checking nothing on the machine
|
||||
changed.
|
||||
- **A machine without the module reads unchecked**, never healthy — asserted on what the mesh says about
|
||||
a machine it is not assigned to.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0144](0144-anything-on-a-machine-may-call-anything-on-it.md) — the three things that must be callable
|
||||
- [ADR 0143](0143-a-consumer-verifies-the-grant-it-is-given.md) — superseded; what survives is that the
|
||||
position matters
|
||||
- [ADR 0053](0053-a-step-that-runs-on-a-schedule.md) — the cadence
|
||||
- [ADR 0138](0138-an-assignment-binds-an-endpoint-and-says-how-far-it-reaches.md) — internal and public,
|
||||
which the probe endpoints declare
|
||||
- [issue 145](../04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md)
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-29
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0145-a-module-checks-what-the-mesh-claims-is-reachable.md
|
||||
supersedes: 02-DECISIONS/0145-a-module-checks-what-the-mesh-claims-is-reachable.md
|
||||
---
|
||||
|
||||
# 146. Connectivity is checked by name, per hosting form, with a valid certificate
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0145](0145-a-module-checks-what-the-mesh-claims-is-reachable.md) decided that a module checks what
|
||||
the mesh claims is reachable, from where the callers are, because the mesh reported four machines healthy
|
||||
for eleven hours while a module could not reach its database
|
||||
([issue 145](../04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md)).
|
||||
That decision stands. What it got wrong is everything about *what* is dialled.
|
||||
|
||||
It dialled a raw port on each machine's address. Three things are wrong with that:
|
||||
|
||||
- **A raw port is not how anything in this mesh is reached.** A real caller resolves a name, the proxy
|
||||
answers it, and the proxy reaches the service. A check that dials a port tests the last hop of a path
|
||||
with four hops in it, and the three it skips — resolution, the proxy, the certificate — are where most
|
||||
of the mesh's connectivity actually lives.
|
||||
- **It tested one hosting form.** A module is software that delivers services, and it may deliver them
|
||||
from a container, from a unit the mesh writes for its own code, or from a unit a package ships. Those
|
||||
are three different paths to the same machine, and the outage that produced this was two of them
|
||||
disagreeing. A probe served one way measures one way.
|
||||
- **It said nothing about certificates.** An internal name that resolves, routes and answers over TLS
|
||||
that nothing can verify is not a working path; it is a working path for whoever holds the proxy's
|
||||
trust and nobody else.
|
||||
|
||||
## Decision
|
||||
|
||||
**Each hosting form gets its own endpoint, its own route and therefore its own name.** On every machine:
|
||||
|
||||
| name | what serves it |
|
||||
|---|---|
|
||||
| `connect-docker.<node>.internal` | a container |
|
||||
| `connect-process.<node>.internal` | the mesh's own code, in a unit the mesh writes |
|
||||
| `connect-unit.<node>.internal` | a unit a package ships |
|
||||
|
||||
and the same set under each machine's public domain where it has one — `connect-docker.<domain>` and its
|
||||
siblings. The names are the instrument: a failure reads as *`connect-docker.g14.internal` did not answer*,
|
||||
which says which machine and which hosting form without anybody interpreting anything.
|
||||
|
||||
**Every machine checks every machine, by name, over TLS, verifying the certificate.** Not a port, not an
|
||||
address: resolve the name, connect, complete the handshake, check the certificate against the authority
|
||||
that should have issued it — the mesh's own for an internal name, a public one for a public name. That is
|
||||
the whole path a real caller takes, and each step failing is reported as itself.
|
||||
|
||||
**No name is written anywhere.** The machines come from the roster the mesh already renders as a fact, and
|
||||
the labels are the module's. A machine that joins appears in every other machine's roster on the next
|
||||
push, and they begin checking it without an edit.
|
||||
|
||||
**And the module arrives on a machine because the machine exists, not because somebody assigned it.** A
|
||||
machine that joins and does not have it is worse than unchecked: every other machine is already dialling
|
||||
its names, so it reads as broken everywhere until someone notices. This is the part the mesh cannot
|
||||
currently express — see below — and it is the part that makes the rest safe.
|
||||
|
||||
**What survives from 0145**, unchanged: it reports and repairs nothing; one failure is not a fault and a
|
||||
path is broken after consecutive runs with the count travelling with the result; findings are said on the
|
||||
bus, because a finding in a file on the machine is what this exists to end; and the bus is the one path
|
||||
that cannot report its own failure, so an emit that does not land is written locally and nowhere else.
|
||||
|
||||
## What this needs that the mesh does not have
|
||||
|
||||
Named here rather than assumed, because each is a decision of its own and this record is not the place to
|
||||
make them:
|
||||
|
||||
1. **A module that every machine has.** `ScopeNode` means *at most one holder per node* — an exclusivity
|
||||
rule, not an obligation — and nothing assigns a module at enrolment. Today the resolver, the packet
|
||||
filter, ssh and intrusion prevention are each assigned per machine by hand, which is the same gap
|
||||
wearing different clothes.
|
||||
2. **A container running a module's own bundle.** A `process` runs the mesh's own compiled code with no
|
||||
image; a `container` needs an image of the module's own, which means a Dockerfile — the thing the
|
||||
`bundle` artifact exists to abolish. Nothing in the catalogue runs a bundle in a container, so
|
||||
`connect-docker` has no shape yet.
|
||||
3. **A unit a package ships, for `connect-unit`.** The `service` resource puts an existing unit into a
|
||||
state and deliberately installs none, so this form needs a package that serves a port — and naming a
|
||||
program the machine may not have is
|
||||
[issue 136](../04-ISSUES/136-a-module-may-name-a-program-the-machine-does-not-have/00-report.md).
|
||||
4. **A machine's public domain in the roster fact.** The fact carries each machine's name, mesh name,
|
||||
address and operator account. The public names cannot be composed without the domain.
|
||||
5. **Something that installs the mesh's own root on a machine.** This is
|
||||
[issue 129](../04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/00-report.md), open
|
||||
since before any of this. Until it is closed, every internal name will fail certificate verification
|
||||
from every machine — correctly, because nothing can verify it. That is the checker working, and it is
|
||||
worth saying in advance so the first run is not read as the checker being broken.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **A failure names the machine and the hosting form.** That is the whole gain over a port: eleven hours
|
||||
became two runs under 0145, and under this it also becomes one line that says where to look.
|
||||
- **The checker surfaces issue 129 immediately**, and will report every internal name unverifiable until
|
||||
it is fixed. A reader must be told that before the first run rather than after.
|
||||
- **Five things must be built before this is what it says it is**, and until they are, what exists is a
|
||||
port dial from one position — useful, and not this.
|
||||
- **What got harder:** a module with three hosting forms of the same trivial service is a strange thing to
|
||||
read. It is justified only because those three forms are how the mesh actually runs software, and a
|
||||
checker that tested one of them would keep the class of outage it exists to catch.
|
||||
|
||||
## How it is checked
|
||||
|
||||
- **A name per hosting form answers from every machine**, asserted by name and not by port.
|
||||
- **A certificate that does not verify is reported as that**, distinctly from a name that does not resolve
|
||||
and a port that does not answer — three faults, three owners.
|
||||
- **A machine that joins is checked by every other machine without an edit**, asserted by adding one to a
|
||||
bed and looking at what the others dial on their next run.
|
||||
- **A machine that joins has the module**, which is gap 1 above and is the assertion that cannot be
|
||||
written yet.
|
||||
- **The measured outage is still caught**: the path from a container to a service on its own machine is
|
||||
closed and `connect-docker.<that node>.internal` fails from that machine while the others still pass.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0145](0145-a-module-checks-what-the-mesh-claims-is-reachable.md) — superseded; its core stands
|
||||
- [ADR 0138](0138-an-assignment-binds-an-endpoint-and-says-how-far-it-reaches.md) — the two reaches these
|
||||
names come from
|
||||
- [ADR 0066](0066-public-routing-is-name-agnostic.md) — a label plus a domain, which is why no name is written
|
||||
- [issue 129](../04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/00-report.md) — what the
|
||||
internal names will fail on until it is closed
|
||||
- [issue 145](../04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md)
|
||||
@@ -0,0 +1,169 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-29
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0098-a-fact-a-provider-makes-at-first-start-is-fetched-from-it.md
|
||||
---
|
||||
|
||||
# 147. A module anchors the mesh's authority on a machine, and takes it away again
|
||||
|
||||
## Context
|
||||
|
||||
The mesh runs its own certificate authority and every internal name is served with a certificate
|
||||
from it. No machine trusts it. On an enrolled, adopted workstation — on the private network,
|
||||
resolving through the mesh's resolver — every internal HTTPS name fails verification with
|
||||
*unable to get local issuer certificate*
|
||||
([issue 129](../04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/00-report.md)).
|
||||
The certificates are genuine; nothing on the machine has ever been told what issued them.
|
||||
|
||||
The authority's only consumer today is a proxy, which fetches the root into a directory of its own
|
||||
and hands it to one program ([ADR 0098](0098-a-fact-a-provider-makes-at-first-start-is-fetched-from-it.md)).
|
||||
That is enough for the proxy and for nothing else: a browser, `git` over HTTPS, `curl`, a package
|
||||
manager and every module that calls another module by an internal name read the machine's trust
|
||||
store, which holds the predecessor's authority and a developer tool's local root, and nothing of
|
||||
the mesh's.
|
||||
|
||||
The predecessor wrote its root into every machine it set up. Removing it was deliberate — an
|
||||
honest failure beats a name that verifies for the wrong reason — and it leaves the mesh with no
|
||||
answer at all until this one lands. It is also what keeps the predecessor alive on the machines
|
||||
that still speak TLS to a mesh name.
|
||||
|
||||
**What makes this a decision rather than a patch** is where the knowledge goes. Two mechanisms in
|
||||
the mesh already write things onto a machine because it is on the private network: `/etc/hosts`
|
||||
and the registry's plaintext trust ([ADR 0082](0082-the-registry-is-reached-by-name-and-trusted-by-the-overlay.md)).
|
||||
Following that precedent, the controller would inject an anchor into every such machine's
|
||||
declaration, and issue 129 proposed exactly that. It would work. It would also put *where this
|
||||
operating system keeps trust anchors* and *which command refreshes its bundles* into the control
|
||||
plane, for a fact the control plane does not have (the root does not exist until the authority has
|
||||
run) and a machine that may have no reason to verify a mesh name at all.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **The controller injects the anchor into every machine on the private network**, the
|
||||
`/etc/hosts` and insecure-registry shape. Rejected: being on the network is what makes the
|
||||
registry reachable, and that is why network presence is the right trigger *there* — the trust
|
||||
and the reachability are the same fact. Trusting an authority is not the same fact as being
|
||||
able to reach it, and the anchor's path and the bundle refresh are a property of the machine's
|
||||
operating system, which is the host's half of the mesh, not the controller's.
|
||||
2. **A new host primitive — a `trust-anchor` resource type.** Rejected for now, not on principle.
|
||||
The host's vocabulary should grow when a shape cannot be said with what exists, and this one
|
||||
can: a file and a service already express it, as the packet filter proves
|
||||
([ADR 0140](0140-the-filter-constrains-what-arrives-from-outside.md), whose module writes a
|
||||
unit file and a service and nothing else). The primitive becomes right the moment a second
|
||||
operating system is in play, because the anchor directory and the refresh command are exactly
|
||||
the difference `internal/system` exists to hold. Until then it would be a vocabulary word with
|
||||
one speaker.
|
||||
3. **A module that requires the authority, fetches its root, installs it as an anchor and
|
||||
refreshes the machine's bundles — and removes both when it is no longer assigned.** Adopted.
|
||||
|
||||
## Decision
|
||||
|
||||
**A machine trusts the mesh's authority because a module put its root there, and stops trusting it
|
||||
when that module is taken away.**
|
||||
|
||||
1. **The module requires `internal-acme-ca`** and reads the provider's bound address and the path
|
||||
it serves its root at. It requires nothing else and provides nothing: it is a consumer of the
|
||||
authority like any other.
|
||||
2. **It fetches the root over the mesh's own network, without prior trust**, because there is no
|
||||
prior trust to have — this is the module that establishes it — and the network is what
|
||||
authenticates the fetch ([ADR 0098](0098-a-fact-a-provider-makes-at-first-start-is-fetched-from-it.md),
|
||||
the same reasoning that lets the proxy fetch it). What it accepts is checked: a body that is
|
||||
not a certificate fails, and the failure is the module's, not a later handshake's.
|
||||
3. **It installs the root where this machine's TLS clients look, and refreshes the extracted
|
||||
bundles** — the command that does the refresh is an ordinary part of the unit that places the
|
||||
anchor, not a new thing the mesh can be asked to do.
|
||||
4. **Removal is symmetric and is the same unit's business.** Undeclared, the host stops the unit;
|
||||
stopping it removes the anchor and refreshes the bundles again. A machine that leaves the mesh
|
||||
stops trusting the mesh, without anybody remembering to go and look.
|
||||
5. **It is an ordinary assignment.** No machine is given it automatically. A machine that verifies
|
||||
a mesh name is assigned it, and a machine that does not is not — which is the same statement
|
||||
the mesh already makes about every other module, and is why this is not the controller's
|
||||
business.
|
||||
|
||||
**One operating system, said out loud.** The anchor directory and the refresh command in the
|
||||
module today are Arch's. On a machine that is not Arch the unit fails, visibly, rather than
|
||||
writing a file nothing reads. That is the accurate failure, and it is the signal that option 2
|
||||
above has become right.
|
||||
|
||||
## How this is checked
|
||||
|
||||
- **The verification that could not succeed before.** On a machine holding the module, a plain
|
||||
client fetches an internal HTTPS name with no `-k` and no bundle argument and verifies. On a
|
||||
machine without it, the same fetch fails with *unable to get local issuer certificate*. Both
|
||||
halves, because only the pair distinguishes "the anchor works" from "something else already
|
||||
trusted it".
|
||||
- **The removal half, in the same bed:** unassign the module, refetch, and the failure returns.
|
||||
Checking only the arrival is how a trust store fills up with authorities nobody can account for.
|
||||
- **What is deliberately not checked here:** that the authority issues, that a name resolves, that
|
||||
the proxy serves. Those have their own beds, and this module's bed passing for those reasons is
|
||||
the failure mode this record is most exposed to — which is why the negative half is not optional.
|
||||
|
||||
**What this bed is dialled at, and why it is the authority itself.** The authority serves its own
|
||||
API with a certificate it issued, so the handshake under test needs nothing else in the mesh to be
|
||||
right. A trust bed that reached for a routed name through the proxy would be passing or failing for
|
||||
the proxy's reasons and the resolver's.
|
||||
|
||||
**Written, and not yet run** *(2026-09-29)*. The bed is `trust-anchor` in the lab, and it cannot
|
||||
execute: raising a foundation fails before any module is reached, in both bundles that exist
|
||||
([issue 146](../04-ISSUES/146-the-foundation-cannot-be-raised-on-the-bus-the-mesh-runs-on/00-report.md)).
|
||||
So what stands behind this record today is the rendering — the script the machine would run names
|
||||
the authority it was bound to, checked in the control plane's own test suite — and **not** a machine
|
||||
that verified anything. That is a weaker thing than the paragraph above describes, and it stays
|
||||
written this way until the bed runs.
|
||||
|
||||
> **Progressive insight — 2026-09-30. It has now been run, on the live mesh rather than in the bed.**
|
||||
> The paragraph above said nothing had verified anything, and something has. The module was registered
|
||||
> from the catalogue, assigned to a workstation, and checked in the form this section prescribes — the
|
||||
> authority's own API, so the handshake needs nothing else in the mesh to be right:
|
||||
>
|
||||
> ```
|
||||
> $ curl -sS -o /dev/null -w '%{http_code}' https://<the authority>:9000/health
|
||||
> 200
|
||||
> subject=CN=Step Online CA
|
||||
> issuer=O=Mesh Internal CA, CN=Mesh Internal CA Intermediate CA
|
||||
> Verify return code: 0 (ok)
|
||||
> ```
|
||||
>
|
||||
> **Both halves.** Unassigning and pushing removed the anchor, emptied the trust store of the mesh's
|
||||
> authority, and returned the plain client to *unable to get local issuer certificate* — then assigning
|
||||
> again restored it. The negative half is what distinguishes the anchor working from something else
|
||||
> having trusted it, and it is the half nothing had ever exercised.
|
||||
>
|
||||
> **One thing this found that is not in the module.** The removal only works because the *host* removes
|
||||
> the service before the script: stopping the unit is what deletes the certificate and refreshes the
|
||||
> bundles, and it needs the script it calls to still exist. Nothing in the module states that ordering;
|
||||
> the symmetry this record claims rests on it.
|
||||
>
|
||||
> Run on the live mesh because that is where a change is verified now
|
||||
> ([ADR 0149](0149-the-live-mesh-is-the-test-bed.md)), and the bed still cannot raise a foundation. The
|
||||
> evidence is [issue 129](../04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/02-resolution.md).
|
||||
> Extended the same day to every converged machine — `novox`, `g14` and `shanks` each hold the anchor
|
||||
> and verify with a plain client. `ace` is excluded on purpose: it is adopted, so a module assigned
|
||||
> there is held rather than run, which is right and is not trust.
|
||||
|
||||
## Consequences
|
||||
|
||||
The predecessor's authority can be retired from a machine once this module is assigned to it,
|
||||
which is the first time that has been true. `git` over HTTPS to the mesh's forge starts working,
|
||||
so the ssh-only clone URL stops being a rule. A module on any machine can call another module's
|
||||
internal name and verify it.
|
||||
|
||||
What got harder: one more module to assign to a machine that needs it, and the machine's trust
|
||||
store now changes when an assignment changes — which is the point, and is also a thing an operator
|
||||
can be surprised by. The fetch without prior trust is the same exposure ADR 0098 accepted, now on
|
||||
every machine that holds the module rather than only where a proxy runs: anything that can stand
|
||||
in the middle of the mesh's own network at the moment of the fetch can be believed. The mesh
|
||||
already treats that network as the thing it authenticates.
|
||||
|
||||
## References
|
||||
|
||||
- [issue 129](../04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/00-report.md) —
|
||||
the symptom and the evidence.
|
||||
- [ADR 0098](0098-a-fact-a-provider-makes-at-first-start-is-fetched-from-it.md) — a fact made at
|
||||
first start is fetched from its provider; this extends it from one program to the machine.
|
||||
- [ADR 0082](0082-the-registry-is-reached-by-name-and-trusted-by-the-overlay.md) — the precedent
|
||||
this deliberately does not follow, and why it is right where it is.
|
||||
- [ADR 0005](0005-the-node-host.md) — the host is where one operating system's difference lives.
|
||||
- [`03-DESIGN/01-to-be/08-connectivity.md`](../03-DESIGN/01-to-be/08-connectivity.md).
|
||||
@@ -0,0 +1,176 @@
|
||||
---
|
||||
topic: the tiers
|
||||
status: accepted
|
||||
date: 2026-09-30
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0066-public-routing-is-name-agnostic.md
|
||||
---
|
||||
|
||||
# 148. The mesh's names are resolved, not copied into every container
|
||||
|
||||
## Context
|
||||
|
||||
The mesh gives every container it declares the whole roster of mesh names as entries written into
|
||||
the container's own hosts file at creation
|
||||
([design 08 §2](../03-DESIGN/01-to-be/08-connectivity.md),
|
||||
[ADR 0066](0066-public-routing-is-name-agnostic.md)). A container takes those entries once and never
|
||||
looks again.
|
||||
|
||||
Three issues are the same fact arriving three times.
|
||||
|
||||
**A container keeps the address it was made with.** Adopting the predecessor's tunnel moved the hub's
|
||||
private address; the declaration followed it within one push and nothing on the machine did. The
|
||||
forge's container held the old address, lost its database, reported healthy while its existing
|
||||
connections lasted, and then the public name went down
|
||||
([issue 109](../04-ISSUES/109-a-container-keeps-the-address-it-was-made-with/00-report.md)).
|
||||
|
||||
**The same fault, four days later, undetected for five days.** One container had restarted 2286 times
|
||||
against a database it could no longer find, while the mesh reported the machine as doing what it was
|
||||
told. Inside it, `novox.internal` was an address that had not existed for five days
|
||||
([issue 135](../04-ISSUES/135-a-containers-mesh-names-are-not-compared/00-report.md)). Forty-eight
|
||||
other containers were current, none of them corrected — each had been recreated for some other
|
||||
reason and picked up the roster on the way.
|
||||
|
||||
135 was fixed by putting the roster into the digest the host compares a container against, so a
|
||||
container whose names moved is recreated like one whose image moved. **That made the roster part of
|
||||
every container's identity**, which is the third arrival:
|
||||
|
||||
**One name moving replaces every container in the mesh.** Migrating one small module on one machine
|
||||
took four routine actions; each changed the roster, and each replaced every container on the control
|
||||
node — its own store, the registry, the edge proxy, the forge, the directory, mail. The control plane
|
||||
was unreachable twice while its own store came back through crash recovery
|
||||
([issue 151](../04-ISSUES/151-a-new-name-recreates-every-container-in-the-mesh/00-report.md)). None of
|
||||
the replaced containers had anything to do with the module being migrated, or with its machine.
|
||||
|
||||
The blast radius of a name is now every container that carries the list, which is all of them. The
|
||||
node-by-node migration ahead adds names one module at a time — on one machine alone that is around
|
||||
twenty-five — and each would be a full restart of every service on the hub.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. Keep the roster in every container and accept the churn.** Rejected. It is not a cost that can
|
||||
be paid down: the mesh gets more names as it grows, and every name costs a restart of everything.
|
||||
A rollback costs another.
|
||||
|
||||
**2. Scope each container's entries to the names it actually binds.** A container is given the names
|
||||
of the things it declared a requirement on, so a name's blast radius is its consumers. Tidy, needs no
|
||||
new mechanism, and keeps 135's guarantee exactly.
|
||||
|
||||
Rejected, and this is the close one. It contradicts the standing intent that **anything on the mesh
|
||||
can call anything on it** — three cases, same machine, the private network, the public network, and
|
||||
no fourth. Scoping resolution to declared couplings makes a name reachable only where the mesh was
|
||||
told in advance that it would be wanted, and a person debugging inside a container would find names
|
||||
missing that exist everywhere else on the machine. It also leaves the roster in the digest, so the
|
||||
churn returns the moment a widely-bound name moves — smaller, not gone.
|
||||
|
||||
**3. Resolve at lookup time through the machine's resolver, and copy nothing.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**A container resolves the mesh's names through its machine's resolver, at the moment it asks. No
|
||||
mesh name and no mesh address is written into a container, and none is part of a container's
|
||||
identity.**
|
||||
|
||||
The three consequences that make this worth doing:
|
||||
|
||||
- **Staleness stops being possible**, rather than being detected. 109 and 135 are not bugs that were
|
||||
fixed; they are a shape that no longer exists. A name that moves is answered differently by the next
|
||||
lookup, in every container, with nothing recreated and nothing restarted.
|
||||
- **A name's blast radius becomes nothing.** Assigning a module on one machine does not touch a
|
||||
container on another.
|
||||
- **Anything can still call anything**, which option 2 gave up. The resolver answers every mesh name to
|
||||
every asker on the machine, exactly as it answers the machine itself.
|
||||
|
||||
**The resolver is a machine-level process, not a container** — one of the modules that is not a
|
||||
container at all — so a container depending on it is not the circularity it would be if the mesh's
|
||||
own store had to resolve a name through something the store's own runtime had to start first.
|
||||
|
||||
**What a module declares for itself is untouched.** Entries a manifest asks for are the module's own,
|
||||
stay in the container, and stay in its identity: they are part of what the module *is*, they do not
|
||||
move when the mesh's roster does, and the mesh does not know what they mean.
|
||||
|
||||
**The machine's own roster file is untouched.** It is a file, rewritten in place, read by processes and
|
||||
people; nothing restarts when it changes. It is only the *copy into each container* that this ends.
|
||||
|
||||
### The order this lands in, which is not a preference
|
||||
|
||||
**Nothing may stop copying names until resolution works from a container.** Removing the copy first
|
||||
reintroduces 109 and 135 — silently, and on a live mesh, which is exactly how both were found.
|
||||
|
||||
1. **A container on any network can reach the resolver.** Today a container on the runtime's default
|
||||
network asks from an address the converged filter drops, so it has no DNS at all
|
||||
([issue 110](../04-ISSUES/110-a-container-on-the-runtimes-own-network-cannot-reach-the-resolver/00-report.md));
|
||||
and on two of four machines the resolver binds loopback only, so the runtime hands containers a
|
||||
public resolver instead. Both are prerequisites, not related work.
|
||||
|
||||
> **Progressive insight — 2026-09-30, later the same day. The loopback claim was wrong.** The
|
||||
> resolver bound the private address on all four machines; on two the runtime had never been told
|
||||
> to use it, and on all four the resolver discarded a query that arrived on the runtime's bridge.
|
||||
> The step stands; the facts under it were those. Both fixed the same day
|
||||
> ([issue 110's resolution](../04-ISSUES/110-a-container-on-the-runtimes-own-network-cannot-reach-the-resolver/01-resolution.md)),
|
||||
> and step 3 landed after them.
|
||||
2. **The runtime is told which resolver to use, per machine, as a file** — not per container as a
|
||||
creation-time argument, or the resolver's address is back in every container's identity and the
|
||||
problem has only got smaller.
|
||||
3. **Then, and only then, the roster leaves the declaration and the digest.**
|
||||
|
||||
Until step 3 the mesh keeps copying, and keeps comparing. 151 stays open until step 3 lands; it is not
|
||||
closed by this record, only answered by it.
|
||||
|
||||
## How this is checked
|
||||
|
||||
- **A container resolves a name that moved, without being recreated.** Move a name the mesh serves;
|
||||
from a container that was running before the move and has not been touched since, the name answers
|
||||
with the new address. This is the one 109 and 135 would both have failed.
|
||||
- **A name's blast radius is nothing.** Add a routed name on one machine; no container on any other
|
||||
machine is recreated. The apply report on each machine says nothing changed. This is 151.
|
||||
- **Anything calls anything.** From a container on any machine, every `<node>.internal` name and every
|
||||
routed name the mesh serves resolves — including names the module never declared a requirement on,
|
||||
which is the guarantee option 2 would have given up.
|
||||
- **On every network the runtime offers.** The first three hold for a container on the runtime's
|
||||
default network as well as one on a declared network, because the default network is the case that
|
||||
has no DNS today.
|
||||
- **No mesh name is in a container's spec.** A test asserts the digest a host computes for a container
|
||||
does not move when the mesh's roster does, and does move when the module's own declared entries do.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The resolver becomes load-bearing for every container**, where before it was load-bearing for the
|
||||
machine. This is a real cost and is accepted: a resolver that is down is a machine that cannot
|
||||
resolve, which is already true of the machine itself, and is a smaller event than a roster change
|
||||
destroying and recreating every container on the machine.
|
||||
- **Design 08's "a file rather than a resolver" no longer describes containers.** It was written when
|
||||
the mesh had no resolver and it gave the right answer then. The reasoning it rested on — every Linux
|
||||
has a hosts file, no package needed — was already overtaken by names a hosts file cannot express:
|
||||
service names and wildcards under `<node>.internal`, which is why the resolver was built.
|
||||
- **ADR 0066's mesh-wide propagation is kept and its mechanism changes.** A routed name still reaches
|
||||
every asker in the mesh; it reaches them through the resolver rather than by being written into each
|
||||
container. The consequence 0066 records — that an internal issuer's challenge needs the routed name
|
||||
resolvable inside the mesh — holds unchanged and by the same means the machine already uses.
|
||||
- **Issue 110 stops being a container-DNS inconvenience and becomes a prerequisite** for the mesh not
|
||||
restarting itself whenever it learns a name.
|
||||
- **A container that names a resolver of its own has opted out of the machine's**, and the copy this
|
||||
record removes was the only reason such a container could reach anything by a mesh name.
|
||||
|
||||
> **Progressive insight — 2026-09-30, the afternoon this landed. Found the hard way.** The mail
|
||||
> system's admin, behind Mailu's own resolver, lost its database the moment the copy went
|
||||
> ([issue 171](../04-ISSUES/171-a-modules-own-resolver-knows-no-mesh-name/00-report.md)). A `dns` on
|
||||
> a container is a decision about whether mesh names exist inside it, not a preference; the module
|
||||
> was corrected, and whether the controller should refuse the contradiction is that issue's open
|
||||
> question.
|
||||
|
||||
- **A container started by hand gets the mesh's names too**, where before only declared containers did.
|
||||
Design 08 drew that boundary deliberately, on the grounds that reaching into every container is what
|
||||
a nameserver would be for. This record accepts that consequence rather than working around it: a
|
||||
person debugging in a hand-started container resolving the same names as everything else is the
|
||||
behaviour worth having, and it is what "anything can call anything" means.
|
||||
|
||||
## References
|
||||
|
||||
- [issue 151](../04-ISSUES/151-a-new-name-recreates-every-container-in-the-mesh/00-report.md) — one name replaces every container; the question this answers
|
||||
- [issue 135](../04-ISSUES/135-a-containers-mesh-names-are-not-compared/00-report.md) — the roster put into the digest
|
||||
- [issue 109](../04-ISSUES/109-a-container-keeps-the-address-it-was-made-with/00-report.md) — the first arrival
|
||||
- [issue 110](../04-ISSUES/110-a-container-on-the-runtimes-own-network-cannot-reach-the-resolver/00-report.md) — the prerequisite
|
||||
- [ADR 0066](0066-public-routing-is-name-agnostic.md) — routed names propagate mesh-wide; extended here
|
||||
- [design 08 §2](../03-DESIGN/01-to-be/08-connectivity.md) — the file-not-resolver reasoning this narrows
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
topic: building it
|
||||
status: accepted
|
||||
date: 2026-09-30
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
supersedes: 02-DECISIONS/0068-the-lab-takes-requests.md
|
||||
---
|
||||
|
||||
# 149. The live mesh is the test bed
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0068](0068-the-lab-takes-requests.md) proposed that the lab accept queued requests
|
||||
— a bed and a commit — answer them one at a time from a copy it owns, and expose that through tools so
|
||||
an agent could start a run and come back to it. It has been `proposed` since 2026-09-12 and nothing was
|
||||
built.
|
||||
|
||||
What happened instead is that the mesh became the thing under test. It runs on four machines; every
|
||||
fault worth finding in the last month was found on them, and none was found in a bed:
|
||||
|
||||
- a container holding an address that had not existed for five days, on the control node
|
||||
([issue 135](../04-ISSUES/135-a-containers-mesh-names-are-not-compared/00-report.md));
|
||||
- a machine reading healthy for eleven hours while no module could reach another
|
||||
([issue 145](../04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md));
|
||||
- one name replacing every container on the hub
|
||||
([issue 151](../04-ISSUES/151-a-new-name-recreates-every-container-in-the-mesh/00-report.md));
|
||||
- a consumer assertion that is correct on a mesh being raised and fatal on one that is running
|
||||
([issue 156](../04-ISSUES/156-moving-a-consumers-delivery-subject-stops-the-control-plane/00-report.md)).
|
||||
|
||||
The last is the one that settles it. That change was exercised on the raise path — which is what a bed
|
||||
*is* — and the raise path is the only path on which the fault cannot appear. A bed raises a mesh; it
|
||||
does not have a mesh that has been running for weeks, with consumers already bound, containers created
|
||||
against an older roster, and an adopted machine carrying a predecessor's configuration. **The faults
|
||||
that cost the most were all faults of a mesh that already exists**, and a bed is by construction a mesh
|
||||
that does not.
|
||||
|
||||
Lab runs are also expensive in a way that changed the behaviour around them: each costs a build and
|
||||
several minutes, so they were batched, and a batched test is one whose result arrives after the next
|
||||
three changes were already written.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. Build 0068 as proposed.** Rejected. It answers a question nobody is asking: the bottleneck was
|
||||
never that a person had to sit at the lab, it was that a bed cannot hold the state the faults live in.
|
||||
Queueing and tooling a mechanism that finds the wrong class of fault faster is not an improvement.
|
||||
|
||||
**2. Leave 0068 `proposed`.** Rejected, and it is why this record exists rather than nothing. A record
|
||||
that contradicts current practice and sits unresolved is worse than either answer: it reads as intent
|
||||
to anyone who finds it, and the practice it contradicts is written down nowhere but a handoff note.
|
||||
|
||||
**3. Record that the live mesh is the test bed, and supersede 0068.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**A change is verified against the mesh that is running.** Not because a bed would be unwelcome, but
|
||||
because the state that breaks things is state a bed does not have: containers made against an older
|
||||
roster, consumers already bound, an adopted machine, a store with weeks of history.
|
||||
|
||||
**A change that can only be exercised on the raise path is not verified.** If the only test available
|
||||
raises a fresh mesh, the record says so, and says which case was therefore not covered. The words
|
||||
"exercised on a fresh mesh" are a statement about coverage, not a pass.
|
||||
|
||||
**The lab is not retired**, and [ADR 0016](0016-the-lab.md) stands. It remains the place to raise a
|
||||
mesh from bare, which is the one thing the live mesh cannot be asked to do and the one thing a bed does
|
||||
better than anything else. What this record removes is the lab as the *default* answer to "is this
|
||||
change good", and with it 0068's queue, tools and request protocol.
|
||||
|
||||
**Accuracy over a green run.** An honest failure on the live mesh beats a pass in a bed that could not
|
||||
have failed — and a change that is risky on the running mesh is a reason to make the change smaller,
|
||||
not a reason to test it somewhere it cannot break.
|
||||
|
||||
**What 0068 got right is kept as a rule, not a mechanism:** a run reads a copy that is not anybody's
|
||||
working tree. Every run of the lab that mattered was pinned to a checkout rather than a worktree, and
|
||||
the ones that were not produced results about code nobody had written down.
|
||||
|
||||
## How this is checked
|
||||
|
||||
- **A record that says a change was verified says on what.** Where it was a fresh mesh, it says which
|
||||
case is uncovered. This is the clause that would have caught 156: its change was verified, honestly,
|
||||
on the only path where it works.
|
||||
- **The lab is not in the path of a merge.** No check, playbook or handoff requires a bed to have run.
|
||||
- **0068 is unreachable as intent.** Its status is `superseded` and it names this record, so a reader
|
||||
arriving at the queue design finds out immediately that it was not built and why.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **A fault can be introduced on the machines that serve.** This is the cost, it is real, and it was
|
||||
paid twice in one evening — a control plane crash-looping for half an hour, and every container on the
|
||||
hub recreated five times. Both were found in minutes because they were live, and both would have
|
||||
passed a bed.
|
||||
- **There is no pre-merge gate beyond the repositories' own suites.** `make check` and the three hq
|
||||
checks are what stands between a change and the machines, which raises what those suites are worth
|
||||
and makes a test that cannot fail a genuine defect rather than an untidiness.
|
||||
- **Raising a mesh from bare is now the lab's whole job**, and is exercised deliberately rather than
|
||||
as a side effect of testing something else. The foundation work
|
||||
([issue 146](../04-ISSUES/146-the-foundation-cannot-be-raised-on-the-bus-the-mesh-runs-on/00-report.md))
|
||||
is that job, and it is also the proof that the mesh can make another of itself.
|
||||
- **An agent cannot hand a run to a queue and come back**, which 0068 would have given. In practice it
|
||||
watches a push and reads the machines, which is what happened anyway.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0068](0068-the-lab-takes-requests.md) — superseded by this
|
||||
- [ADR 0016](0016-the-lab.md) — the lab, which stands
|
||||
- [issue 156](../04-ISSUES/156-moving-a-consumers-delivery-subject-stops-the-control-plane/00-report.md) — correct on the raise path, fatal on a running mesh
|
||||
+117
@@ -0,0 +1,117 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-30
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0047-a-module-runs-its-code-as-its-own-process-with-its-own-account.md
|
||||
---
|
||||
|
||||
# 150. A module's own code runs as supervised processes under the module's one account
|
||||
|
||||
> **Widened — 2026-10-02, by [ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md).** A module's long-lived process is a bundle in any language the mesh has a toolchain for, run as a unit the host writes; this record never said one language and never meant one, and 0188 says so as the rule.
|
||||
|
||||
> **The mechanism changed — 2026-10-02, by [ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md).** For a module's *tools*, read that record: one runtime per node, the node's one account, bundles loaded from the memberships. This record still governs a module's long-lived processes — a daemon, a provisioner, a scheduled ingest — and the account invariant for them.
|
||||
|
||||
## Context
|
||||
|
||||
The repository answers "what runs a module's own code" two ways and reconciles them nowhere
|
||||
([issue 117](../04-ISSUES/117-a-modules-own-code-is-a-container-and-a-process/00-report.md)).
|
||||
|
||||
[ADR 0047](0047-a-module-runs-its-code-as-its-own-process-with-its-own-account.md) is accepted and
|
||||
says **a container** — "the tool runtime carrying that module's compiled code" — and "one module, one
|
||||
process, one account". Two `proposed` design documents say a **`process`** resource running an argv,
|
||||
supervised by the machine, and one of them declares *four* of them for a single module and presents
|
||||
four as the point. Neither design document names 0047 in its `decisions:`, and the string `process`
|
||||
as a resource type appears in no decision record at all. The thing as built is the container.
|
||||
|
||||
Two things have happened since 0047 was written that bear on it directly.
|
||||
|
||||
[**ADR 0142**](0142-the-mesh-delivers-its-own-components-as-binaries.md) decided that the mesh's own
|
||||
components are binaries on the machine rather than container images, and
|
||||
[issue 114](../04-ISSUES/114-should-the-controller-be-a-container-or-a-process/00-report.md) was closed
|
||||
by it. That settled the mesh's components and deliberately said nothing about a module's.
|
||||
|
||||
And the standing definition of a module hardened: **a module is software that delivers one or more
|
||||
services, and a module is not a container.** It may deliver them as a container, an installed package
|
||||
with a unit, a binary, or configuration files; 61 of 73 happen to use a container and 11 do not,
|
||||
including the resolver, sshd and fail2ban. A rule that a module's *own code* must be a container makes
|
||||
the one kind of module the mesh writes itself the only kind that has no choice.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. Hold 0047 as written: a container.** Rejected. Its own reasoning does not require one. What 0047
|
||||
argued for was a runtime **per module** rather than one for the whole node, because a node-wide runtime
|
||||
could not hold a per-module broker account and per-module runtimes competing on one tool key would each
|
||||
be handed calls for tools they do not have. A supervised unit per module satisfies that argument
|
||||
exactly — it is per module, and a unit runs as an account. The container was the mechanism to hand, not
|
||||
the conclusion.
|
||||
|
||||
**2. Let each design document choose.** Rejected; that is the present state and it is what issue 117
|
||||
reports. A module author reading the guide writes four processes; a module author reading the record
|
||||
writes a container; nothing tells either that the other exists.
|
||||
|
||||
**3. Settle the hosting form as a supervised process, and settle the count separately.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**A module's own code runs as one or more supervised processes on the machine, under the module's single
|
||||
account.** Where [ADR 0047](0047-a-module-runs-its-code-as-its-own-process-with-its-own-account.md) says
|
||||
"a container, the tool runtime carrying that module's compiled code", read this record. Everything else
|
||||
0047 decided stands untouched: a tool is served on its own key, only the module that serves it answers,
|
||||
and the module's account is scoped to exactly its tool keys.
|
||||
|
||||
**The invariant is the account, not the process count.** 0047's "one module, one process, one account"
|
||||
carried its weight in the last clause. Its stated worry about a second process was "not a second one to
|
||||
scope and seal" — a second *identity* to grant, seal a secret to, and scope on the bus. Several
|
||||
processes sharing the module's one account create no second identity, so nothing further is scoped or
|
||||
sealed, and a module may therefore declare as many as its work has shapes: events, tools, a
|
||||
provisioner, a scheduled ingest. **What a module may not have is two accounts.**
|
||||
|
||||
**A module that delivers its service as a container still does.** This record is about the code the
|
||||
module itself carries — its tools, its events, its provisioner — and not about the software it delivers.
|
||||
A module wrapping a third-party image wraps a third-party image.
|
||||
|
||||
**Why supervised by the machine rather than by the mesh:** it is the same answer ADR 0142 gave for the
|
||||
mesh's own components, for the same reason. A unit the machine restarts needs no image, no registry
|
||||
pull and no runtime to be up before the mesh's own code can run — which matters most for exactly the
|
||||
modules whose code the mesh cannot start any other way.
|
||||
|
||||
## How this is checked
|
||||
|
||||
- **No design document describes a hosting form for a module's own code without citing this record.**
|
||||
Designs 18 and 20 name it in `decisions:`; this is the gap issue 117's third point reports, and
|
||||
`cycle.py` already enforces that a to-be design names its decisions.
|
||||
- **A module declaring several processes resolves to one account.** A test composes a module with more
|
||||
than one process resource and asserts the mesh mints exactly one broker account for it, scoped to that
|
||||
module's tool keys and nothing else — which is 0047's invariant stated as an assertion rather than a
|
||||
sentence.
|
||||
- **A module's own code does not require the container runtime.** A machine with no container runtime
|
||||
can still run a module whose code is its own, which is the claim that separates this from option 1 and
|
||||
is checkable on a machine that has one by asserting the declaration names no image for it.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The sidecar port stops being needed.** [ADR 0029](0029-a-network-is-a-shape-because-an-action-cannot-be-undone.md)
|
||||
records that "anything that is a service plus a sidecar currently has to publish a port to talk to
|
||||
itself", and the host's `network` shape exists partly for it. A process beside the service on the same
|
||||
machine reaches it without publishing anything, so that pressure goes.
|
||||
- **Something must supervise, and it is the machine.** This adds a unit per module's code to what the
|
||||
host writes and owns. The mesh already writes and owns units — `nftables` proves a module can write one
|
||||
and run it — so the mechanism exists; the count grows.
|
||||
- **A module's code is delivered, not pulled**, which puts it behind the same gap as the host's own
|
||||
delivery ([ADR 0141](0141-the-host-delivers-its-own-successor.md), not built): nothing yet delivers a
|
||||
version of a module's binary to a machine. A container's code arrives by `docker pull`, and this does
|
||||
not. **This is the cost of the decision and it is not paid**; until delivery exists, a module whose code
|
||||
is its own is a module somebody places by hand.
|
||||
- **Issue 117 is answered and its three disagreements close differently:** container-or-unit is decided
|
||||
here; one-process-or-several is decided here as several under one account; and whether the record was
|
||||
consulted is fixed by designs 18 and 20 naming this one.
|
||||
|
||||
## References
|
||||
|
||||
- [issue 117](../04-ISSUES/117-a-modules-own-code-is-a-container-and-a-process/00-report.md) — the contradiction this answers
|
||||
- [ADR 0047](0047-a-module-runs-its-code-as-its-own-process-with-its-own-account.md) — extended; its "a container" clause is settled here
|
||||
- [ADR 0142](0142-the-mesh-delivers-its-own-components-as-binaries.md) — the same answer for the mesh's own components
|
||||
- [ADR 0141](0141-the-host-delivers-its-own-successor.md) — the delivery this depends on and which is not built
|
||||
- [ADR 0029](0029-a-network-is-a-shape-because-an-action-cannot-be-undone.md) — the sidecar port this relieves
|
||||
+104
@@ -0,0 +1,104 @@
|
||||
---
|
||||
topic: the tiers
|
||||
status: accepted
|
||||
date: 2026-09-30
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0066-public-routing-is-name-agnostic.md
|
||||
---
|
||||
|
||||
# 151. A route's internal name is composed under the node that serves it
|
||||
|
||||
> **Narrowed, not replaced — 2026-10-03.** *"The roster publishes it as itself, once, at the serving
|
||||
> node's address"* no longer holds: a public name is never given a private answer, and resolves publicly
|
||||
> ([ADR 0191](0191-the-meshs-resolver-holds-only-the-meshs-own-names.md)). The internal name this record
|
||||
> composes is what that rests on, and stands.
|
||||
|
||||
## Context
|
||||
|
||||
A module that requires a route is given two names from one label: a public one, `<label>.<public
|
||||
domain>`, and an internal one, `<label>.<node>.internal`
|
||||
([ADR 0138](0138-an-assignment-binds-an-endpoint-and-says-how-far-it-reaches.md)). Both were composed
|
||||
from the node the module runs on.
|
||||
|
||||
The two are answered differently. The public name is published into every machine's roster at the
|
||||
address of the node whose proxy serves it ([ADR 0066](0066-public-routing-is-name-agnostic.md)), so
|
||||
it reaches the proxy from anywhere in the mesh. The internal name is answered by every machine's
|
||||
resolver as *anything under a node's name goes to that node*
|
||||
([design 08 §2](../03-DESIGN/01-to-be/08-connectivity.md)) — the node it was composed from, which is
|
||||
the consumer's. Where the proxy runs on another machine, that name sends a client to a machine with
|
||||
nothing listening, while the public name works
|
||||
([issue 139](../04-ISSUES/139-an-internal-route-name-resolves-to-the-consumers-node/00-report.md)).
|
||||
Every route on this mesh today is served beside its module, so it has not been seen; `route` is
|
||||
provided mesh-wide precisely so that stops being true.
|
||||
|
||||
Beside it, the roster gave every routed name a second entry with the mesh's suffix appended —
|
||||
`<name>.<public domain>.internal` — because it composed a full name for every entry as it does for a
|
||||
machine. That name resolved on every machine, was served by nothing, and was refused by the proxy at
|
||||
the handshake; the first three names tried while reproducing an unrelated issue were those, and the
|
||||
evidence pointed at a regression that had not happened
|
||||
([issue 157](../04-ISSUES/157-a-routed-names-internal-alias-is-served-by-nothing/00-report.md)).
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. Keep the consumer's name and publish it at the serving node's address**, as the public name is.
|
||||
The name stays `<label>.<consumer>.internal` and an exact roster entry overrides the wildcard.
|
||||
Rejected: it makes `<x>.<node>.internal` mean *goes to that node* except when it does not, which is
|
||||
the one rule the resolver design states; it needs an entry per route where the wildcard needed none;
|
||||
and which of an exact entry and a wildcard a resolver answers first is the resolver's business, which
|
||||
the mesh deliberately does not know.
|
||||
|
||||
**2. A proxy on every machine, so the serving node is always the consumer's.** Rejected for this
|
||||
question: it is a different decision about what `route` is — a node-scoped seat with a mesh-wide
|
||||
fallback — and this mesh runs one proxy on the hub today. Whatever is decided there, a route served
|
||||
from another machine must have a name that reaches it.
|
||||
|
||||
**3. Compose the internal name under the node that serves the route.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**A route's internal name is `<label>.<serving node>.internal` — composed under the node whose proxy
|
||||
answers the route, which is the machine the request arrives at.** The public name is unchanged:
|
||||
`<label>.<public domain>` of the node the module runs on, which is where the operator put it.
|
||||
|
||||
Where the proxy runs beside the module — every route on this mesh today — the two nodes are one and
|
||||
nothing changes. Where it does not, the name says where the request goes, which is what a name under
|
||||
a node's name has always meant.
|
||||
|
||||
**A routed name has no mesh form.** The roster publishes it as itself, once, at the serving node's
|
||||
address. Only a machine has a bare name beside its full one.
|
||||
|
||||
What certifies the internal name is unchanged by this: the proxy that terminates it obtains a
|
||||
certificate from the mesh's authority for the names it is given, and it is given this one.
|
||||
|
||||
Taken on the operator's standing instruction to answer the open design questions in the work order.
|
||||
|
||||
## How this is checked
|
||||
|
||||
- **Composition.** A controller test contributes a route from a module on one node to a proxy offered
|
||||
from another, gathered the way the controller gathers a consumer's contribution for a provider on
|
||||
another machine, and asserts the internal name carries the serving node.
|
||||
- **Publication.** A controller test renders a roster with a machine and a routed name and asserts
|
||||
the routed name appears as itself, once, and never with the suffix appended.
|
||||
- **On the mesh.** After the change no machine's roster carries a `<domain>.internal` entry, and a
|
||||
route's internal name still answers from a container with a certificate from the mesh's authority.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **A route served from another machine now has a usable internal name.** The first module assigned
|
||||
that way will resolve, where before it would have resolved to the wrong machine with no error.
|
||||
- **The internal name of a route can change when its proxy moves.** A route re-homed from one proxy
|
||||
to another gets a new internal name, as the design's rule implies; clients that dialled the old one
|
||||
reach the old machine. The public name does not move with the proxy and is the stable one.
|
||||
- **The roster is one line shorter per routed name**, and a person reading a hosts file no longer
|
||||
finds names that resolve to a refusal.
|
||||
- **Issue 139's second question — a per-node route holder — is left open**, and is a decision about
|
||||
what a seat is rather than about a name.
|
||||
|
||||
## References
|
||||
|
||||
- [issue 139](../04-ISSUES/139-an-internal-route-name-resolves-to-the-consumers-node/00-report.md) — the question
|
||||
- [issue 157](../04-ISSUES/157-a-routed-names-internal-alias-is-served-by-nothing/00-report.md) — the alias
|
||||
- [ADR 0066](0066-public-routing-is-name-agnostic.md) — routed names propagate mesh-wide; extended here
|
||||
- [ADR 0138](0138-an-assignment-binds-an-endpoint-and-says-how-far-it-reaches.md) — how the two names are composed and how far each reaches
|
||||
- [design 08 §2](../03-DESIGN/01-to-be/08-connectivity.md) — anything under a node's name goes to that node
|
||||
@@ -0,0 +1,162 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-30
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0095-the-control-plane-is-the-way-to-ask-a-module.md
|
||||
---
|
||||
|
||||
# 152. The operator's surface is a module the mesh assigns: the console
|
||||
|
||||
## Context
|
||||
|
||||
**Since the bus moved, nobody can ask the mesh anything without opening a shell on a machine.** Every
|
||||
tool call an operator's assistant makes fails, on every machine including the one the operator sits
|
||||
at, with *AMQP not connected*
|
||||
([issue 147](../04-ISSUES/147-the-operators-tools-still-dial-the-bus-that-was-removed/00-report.md)).
|
||||
The program answering is the predecessor's tool server, started on the workstation by hand, with the
|
||||
predecessor's broker address written into the assistant's own configuration. It has no manifest, no
|
||||
assignment, no account on the bus, and the mesh has never known it exists. Nothing regressed: the
|
||||
mesh removed a transport that a program outside the mesh still dials.
|
||||
|
||||
**The mesh has a tool model, and it works.** A module serves each tool on its own subject and its
|
||||
account may serve nothing else ([ADR 0047](0047-a-module-runs-its-code-as-its-own-process-with-its-own-account.md));
|
||||
a person is issued an account whose only permission is to publish the tool subjects named at issue
|
||||
([25 — The bus on NATS](../03-DESIGN/01-to-be/25-the-bus-on-nats.md) §7); a client on the
|
||||
runtime repository's main branch speaks that account as a command line and as an MCP server. Measured
|
||||
on the live mesh on 2026-09-28: a call to the forge's `gitea_list_repos` answered with real
|
||||
repositories; the tool list came back empty, because it asks the catalogue for a tool nothing serves
|
||||
([ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md)).
|
||||
|
||||
**Two records have already said where the surface belongs.** ADR 0132's consequences: *the MCP
|
||||
surface belongs inside the mesh — a module the mesh assigns to the machine where the agent sits, with
|
||||
a credential the mesh minted and authority derived from what it may call, not a program started by
|
||||
hand with a credential printed to a terminal.* Design [33](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md)
|
||||
§6 says the same. Neither is a decision about the surface: 0132 decided where a seat's tools live,
|
||||
and named the surface in passing.
|
||||
|
||||
**And one record says the opposite, in the letter.** [ADR 0095](0095-the-control-plane-is-the-way-to-ask-a-module.md)
|
||||
made the control plane *the* way to ask a module, deferred "calling is a grant" until something asked
|
||||
for it, and recorded that *nothing outside the control plane can*. A person's account (design 25 §7,
|
||||
built 2026-09-28) is exactly that grant, minted for a person. So 0095's exclusivity has already been
|
||||
widened once without a record saying so; a module that calls tools widens it a second time, and this
|
||||
record is where that is said.
|
||||
|
||||
**What a module's account may do today, counted from the composition** (`internal/broker`): publish
|
||||
its own events, publish the accept subjects of seats it uses, subscribe its own tools and what it
|
||||
consumes. No module principal may publish another module's tool subject. Of 72 modules in the
|
||||
catalogue, 45 serve tools and 0 may call one.
|
||||
|
||||
The question the work order asks before any code: **does the mesh grow its own operator surface, or is
|
||||
the surface an ordinary module that happens to serve tools?**
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. The control plane serves the agent protocol itself** — a listener on the controller, or a verb
|
||||
its binary runs. Rejected. It puts a surface for tools the control plane does not implement on the one
|
||||
component that must stay answerable while it is itself being replaced, which is the reason 0132
|
||||
rejected the control plane as the answer to discovery. A person on a workstation would reach it over
|
||||
the network, and the networked surface [ADR 0035](0035-one-implementation-several-surfaces.md)
|
||||
reserves for that authenticates through an OAuth2 provider that is not configured — so the controller's
|
||||
`api` verb correctly serves nothing today, and this option would either wait for it or bypass it.
|
||||
|
||||
**2. A program a person installs and starts by hand with a printed credential** — what exists on the
|
||||
runtime repository's main. Rejected as the end state. It is outside the mesh in every way issue 147
|
||||
names: no assignment, no declaration, no seat, no check that it reaches anything, revoked only by a
|
||||
person remembering to. It is the predecessor's arrangement one bus later, and it fails the same way
|
||||
the next time an address moves. It stays as the recovery path, the way the command line does
|
||||
(ADR 0035): a credential from `operator issue` and the `mesh` client work with no console assigned.
|
||||
|
||||
**3. An ordinary module, assigned to the machine the person sits at, holding a credential the mesh
|
||||
minted, serving the mesh's tools on that machine's loopback.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**The console is a module.** `mesh-console` is built by the mesh, registered like any module,
|
||||
assigned to a machine, and given a bus credential sealed to that machine. It serves the mesh's tools to
|
||||
whoever is on that machine: to an agent over MCP, and to a person through the same endpoint. Assigning
|
||||
it to a machine is what makes the mesh reachable from there; unassigning it revokes that, at the next
|
||||
composition, with nothing on the machine to remember to remove.
|
||||
|
||||
**A grant to call is a manifest word: `invokes`.** A module declares the tools it calls, each as
|
||||
`<module>.<tool>`, or the single entry `*` for every tool on the mesh. The bus grants exactly that
|
||||
publish side and nothing beside it — no event, no subscription, no seat. This is ADR 0095's deferred
|
||||
first option, taken now that a consumer asks for it; a person's account already has this shape, and
|
||||
the same composition derives both. The control plane's `ask` stands, and 0095's audit point with it:
|
||||
every call still passes one account whose permission list says what it may ask.
|
||||
|
||||
**Authority is the machine's login.** The console listens on the machine's loopback only, declared
|
||||
`from: machine`, so whoever can open a socket on the machine is whoever owns the machine, and *the
|
||||
account that installed the host owns the mesh on that node*
|
||||
([ADR 0034](0034-the-local-account-owns-the-mesh.md)). Anything on a machine may call anything on it,
|
||||
and that is the whole of local ([ADR 0144](0144-anything-on-a-machine-may-call-anything-on-it.md)).
|
||||
The mesh knows no person: what the audit sees is which console asked, under the account
|
||||
`<node>.mesh-console`. How a person's identity reaches a session is the question design 15 leaves
|
||||
open, and this record does not close it.
|
||||
|
||||
**What the console lists is asked of the modules.** Design 33 §5: a module's own tools are answered by
|
||||
the module, from the code that defines them. The tool runtime therefore answers one reserved verb for
|
||||
every module it serves — `tools`, the module's tool names, descriptions and argument schemas — and the
|
||||
console assembles its list by asking the catalogue which modules the mesh holds and each module what
|
||||
it answers. A module that is not running is absent from the list and says so; a tool an agent already
|
||||
knows the name of can be called whether or not it was listed. A module may not name a tool of its own
|
||||
`tools`; the runtime refuses the collision at load rather than letting one shadow the other. A
|
||||
role's tools, and the mesh's own verbs, join the list when the `mesh-controller` seat serves them
|
||||
(design 33 §1, third family) — the console reads whatever the mesh can say about itself, and grows as
|
||||
that does.
|
||||
|
||||
**The console holds one credential and one grant: `*`.** It is the operator's surface on a machine the
|
||||
operator owns; narrowing what it may call is a setting on its assignment, which
|
||||
[ADR 0046](0046-a-module-configuration-is-its-assignments-not-its-manifest.md) already provides for
|
||||
and nothing here builds.
|
||||
|
||||
> **The mechanism changed — 2026-10-02, by [ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md).** The surface stays a module assigned per node, on loopback, with the machine's login as the authority. It is no longer a container: it is the node tools runtime's serving mode, host-side, and that runtime also serves every assigned module's tools. The module is renamed `node-tools`.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The way a person drives the mesh is inside the mesh.** It is declared, delivered, replaced and
|
||||
revoked by the same machinery as everything else, and `status` says whether the machine carrying it
|
||||
has applied. Issue 147's shape — a surface kept alive by an address in a file — cannot recur, because
|
||||
there is no file: the console's credential names the bus the mesh is on, and moves when it does.
|
||||
- **A module may now call tools, which ADR 0095 had reserved to the control plane.** The grant is
|
||||
explicit, per tool or `*`, and derived by the same composition that grants everything else. A module
|
||||
that declares no `invokes` gains nothing. What got harder: a manifest reviewer has one more field to
|
||||
read for authority, and `*` in it deserves the reader's attention every time.
|
||||
- **A new manifest word ships one release before any manifest uses it**, and must reach both parsers:
|
||||
the build machine's and the running controller's. The console's manifest cannot be registered until
|
||||
the controller and the builder that packages it have been rebuilt with the word.
|
||||
- **Discovery costs a fan-out per list.** One request per module the mesh holds, answered at once by
|
||||
the bus for every module nothing serves, so the cost is bounded by the modules that are up. The list
|
||||
is cached briefly in the console; a module assigned a moment ago appears at the next refresh.
|
||||
- **Every tool runtime must be rebuilt once** to answer `tools`. Until a module is, it is callable and
|
||||
not listed, and the console says which modules did not answer.
|
||||
- **The mesh's own verbs are not in the console yet.** `status`, `push`, `assign` are the
|
||||
`mesh-controller` seat's tools under 0132, and the three prerequisites 0132 names are still not in
|
||||
place. A person asking what a node runs still opens a shell for that question, and that gap is design
|
||||
33's to close, not this record's — recorded here so nobody reads the console as the whole of 147.
|
||||
- **The person's credential is not retired.** `operator issue` and the `mesh` client remain the path
|
||||
when no console is assigned, and the path an operator uses to bring a mesh up far enough to assign
|
||||
one.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A module's `invokes` becomes exactly that publish grant, and nothing else | the bus user composition test: a module invoking `shop.price` may publish that subject and no other tool's; `*` may publish every tool subject; neither may publish an event or subscribe anything it did not consume |
|
||||
| A malformed `invokes` entry is refused at registration | a parser test: an entry naming no tool is a problem named in the manifest's words |
|
||||
| The runtime answers `tools` for every module it serves | the runtime's test: a module registering two tools answers three names, and a module naming one of its own `tools` is refused at load |
|
||||
| The console's list is what the modules answer | the client's test against a real bus: two modules up, a third the catalogue holds and nothing serves, and the list carries the two and names the third as not answering |
|
||||
| A call from the console reaches a module over the bus | the same test, and the live mesh: the console assigned to a workstation answers `tools/list` on its loopback and a call to the forge returns repositories |
|
||||
| The console listens on loopback and nowhere else | its manifest declares `from: machine`, and the filter composed for the machine opens nothing for it |
|
||||
|
||||
## References
|
||||
|
||||
- [issue 147](../04-ISSUES/147-the-operators-tools-still-dial-the-bus-that-was-removed/00-report.md) — the surface outside the mesh
|
||||
- [ADR 0095](0095-the-control-plane-is-the-way-to-ask-a-module.md) — extended: a grant to call, for a module as for a person
|
||||
- [ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md) — where a seat's tools live, and the sentence that named the surface
|
||||
- [ADR 0035](0035-one-implementation-several-surfaces.md) — three surfaces over one implementation
|
||||
- [ADR 0034](0034-the-local-account-owns-the-mesh.md), [ADR 0144](0144-anything-on-a-machine-may-call-anything-on-it.md) — why loopback is the authority boundary
|
||||
- [33 — The tools the mesh answers](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md) §5, §6 — discovery, and what serves it to an agent
|
||||
- [34 — The console](../03-DESIGN/01-to-be/34-the-console.md) — the design this record authorises
|
||||
- mesh-tools `src/client.ts`, `src/mcp.ts`, `src/mesh.ts` — the client this makes a module of
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
topic: how we work
|
||||
status: accepted
|
||||
date: 2026-09-30
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0025-the-design-record-is-read-not-copied.md
|
||||
---
|
||||
|
||||
# 153. The record is read by a module the mesh assigns, and the console lists it
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0025](0025-the-design-record-is-read-not-copied.md) decided that this repository is **read where
|
||||
it is written, never copied to be found**: an agent reads it directly, and a search of the mesh's
|
||||
memory consults that agent so its answers appear beside ordinary results. It named the check that
|
||||
closes [issue 006](../04-ISSUES/006-hq-is-not-indexed-into-the-knowledge-base/00-report.md): search
|
||||
for a phrase that appears only in a design document here, and get it back. It gated the build on an
|
||||
agent that did not exist — the mesh session of
|
||||
[15 — The agent session](../03-DESIGN/01-to-be/15-the-agent-session.md) — and on a search that
|
||||
does not exist either, now: the knowledge base 0025 meant was the predecessor's, and since the
|
||||
cut-over nothing reaches it ([issue 147](../04-ISSUES/147-the-operators-tools-still-dial-the-bus-that-was-removed/00-report.md)).
|
||||
|
||||
**So the two halves of 0025 have no home.** There is no store to be "beside", and no session to be
|
||||
the reader. What the mesh has instead, since today: a tool model in which every module answers what
|
||||
it serves, and a console on the machine a person sits at that lists every tool the running modules
|
||||
answer ([ADR 0152](0152-the-operators-surface-is-a-module-the-console.md)). An agent holding the
|
||||
console does not search a store; it reads a tool list and calls what fits the question.
|
||||
|
||||
**What 0025 could not tolerate was a derived copy** — the enforced copy winning while the reasoned one
|
||||
quietly stops being true. It rejected a sync for that reason and for no other. A git checkout is not a
|
||||
derived copy: it is the same bytes at a commit the answer names, and the only way it can differ from
|
||||
the source is by lagging behind it, which is measurable and stated. 0025's own words allow it —
|
||||
*retrieval is an agent reading this repository, not a copy living in a second store* — and the
|
||||
transformation that makes a copy dangerous is exactly what a checkout does not do.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. Wait for the mesh session.** Rejected. Design 15 is `designed` with nothing built, its model
|
||||
access is a provisions question with no consumer identity yet, and 006 has waited since 2026-08-23.
|
||||
A record whose check cannot run is a rule enforced by nothing.
|
||||
|
||||
**2. The console reads the repository itself.** Rejected. The console holds nothing and decides
|
||||
nothing (ADR 0152, ADR 0035); a reader inside it would be a second implementation of a thing that
|
||||
should be one module, unavailable to a person's client and to any other module.
|
||||
|
||||
**3. A module that keeps a checkout of the repository and answers questions about it, listed by the
|
||||
console like any tool.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**The reader is a module: `records`.** It requires the `git` provision — the forge — clones the
|
||||
repository its settings name, keeps the checkout current on every merge the forge announces and on a
|
||||
timer, and answers over the bus: where a phrase appears as written (document, line, nearest heading),
|
||||
one document whole, what a folder holds, and where the checkout stands — always with the commit it
|
||||
read. Nothing is indexed, ranked or summarised: a design record is found by its own words, and a
|
||||
reader deciding which words matter would be a second opinion about somebody else's document.
|
||||
|
||||
**The repository is a setting, not a manifest field.** The module names no mesh
|
||||
([ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md)): which repository it reads is
|
||||
the assignment's business, and an installation that keeps its record elsewhere sets that. Until a
|
||||
repository is set it serves no tools and says why. Public repositories only; it asks for no
|
||||
credential, because a secret it did not need would be one more thing to seal.
|
||||
|
||||
**"Beside everything else" is the console's tool list.** 0025's second half — the search consults the
|
||||
agent — has no store to consult and needs none: the console lists `records_search` beside the forge's
|
||||
tools and the mesh's own verbs, with a description that says when to call it, and an agent choosing
|
||||
tools for a symptom is the search. That is surfacing, not merely reaching: nobody has to know this
|
||||
repository exists to be offered it.
|
||||
|
||||
**Reading stays one-way.** The module reads the forge and answers; nothing flows back into the
|
||||
repository. It holds no credential that could write.
|
||||
|
||||
**The mesh session, when it exists, is a caller of this module, not a replacement for it.** Design 15's
|
||||
*it holds the design record by reading it* is satisfied by asking `records`; the session brings
|
||||
judgement, this brings the text.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **Issue 006 closes on 0025's own check**, run through the console: `records_search` for a phrase
|
||||
that appears in one design document here returns that document. The module's test does the same
|
||||
against a repository it makes.
|
||||
- **The as-is knowledge document is rewritten.** [`07-knowledge.md`](../03-DESIGN/00-as-is/07-knowledge.md)
|
||||
described the predecessor's two stores; neither is reachable from the mesh, and what the mesh knows
|
||||
is now what its modules answer. Saying otherwise is the failure this repository exists to name.
|
||||
- **A checkout lags.** Between a merge and the next sync — seconds when the forge announces it,
|
||||
minutes when it does not — an answer is the previous commit's, and says which. That is the cost of
|
||||
no copy, and it is a number rather than a silence.
|
||||
- **The reader depends on the forge module's event, by name.** `consumes: gitea.pull.merged` names a
|
||||
module rather than the `git` seat, because the seat declares no events. A forge that is not gitea
|
||||
leaves the timer as the only refresh, which still works.
|
||||
- **What got harder:** the record is now reachable from every machine holding a console, which is what
|
||||
was wanted, and a reader must remember that this repository is public and the mesh is not — the
|
||||
module reads the public repository and nothing about the installation.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A phrase in one document comes back from where it is written, with the commit | the module's test against a repository it makes; and live, through the console |
|
||||
| A merge on the origin is pulled and the next answer names the new commit | the same test |
|
||||
| A path outside the checkout is refused, not resolved | a test per shape |
|
||||
| A failed sync leaves the checkout standing and is said | a test against an unreachable origin |
|
||||
| Without a repository set, no tools are served and the log says why | the module's own start |
|
||||
| The console lists `records_search` beside every other tool | the console's listing, live |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0025](0025-the-design-record-is-read-not-copied.md) — extended: the reader is a module, the search is the console's list
|
||||
- [ADR 0152](0152-the-operators-surface-is-a-module-the-console.md) — what lists it
|
||||
- [issue 006](../04-ISSUES/006-hq-is-not-indexed-into-the-knowledge-base/00-report.md) — what closes
|
||||
- [35 — Reading the record](../03-DESIGN/01-to-be/35-reading-the-record.md) — the design
|
||||
- mesh-catalog `modules/records` — the module (PR 183)
|
||||
@@ -0,0 +1,140 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-09-30
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0132-a-seat-carries-the-tools-its-holder-must-serve.md
|
||||
---
|
||||
|
||||
# 154. The mesh's own verbs are the mesh-controller seat's tools, and which verbs those are
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md) decided that a seat's protocol
|
||||
carries its tools in full, that holding a seat means serving them, and that the mesh's own verbs are
|
||||
the `mesh-controller` seat's. It named three prerequisites, none in place: the protocol in the store
|
||||
rather than in compiled defaults; a protocol richer than a list of verbs; a node-scoped seat's subject
|
||||
carrying the node. And it left one thing to a decision per seat: **which verbs each seat serves**,
|
||||
because a seat's tools bind every future holder.
|
||||
|
||||
The console shipped the same day ([ADR 0152](0152-the-operators-surface-is-a-module-the-console.md))
|
||||
and made the gap visible from the operator's chair: a person on a workstation could call every tool a
|
||||
*module* serves and none of the mesh's own. What a node runs, what is assigned, whether a push
|
||||
applied — the questions issue 147 opened with — still meant a shell on the control node. The console's
|
||||
own handshake said so.
|
||||
|
||||
The control plane already answers every one of those questions, as commands: `status --json`,
|
||||
`node show`, `plan --json`, `assign`, `push`. [ADR 0035](0035-one-implementation-several-surfaces.md)
|
||||
says a surface is an adapter over those with no decisions in it, and the `api` verb proves the shape:
|
||||
every route calls the function the command line calls.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. Leave the mesh's verbs to the shell until an identity provider authenticates the HTTP API.**
|
||||
Rejected. The authenticated network surface is for a browser on another machine; the console is
|
||||
already behind the machine's login (0152), and the bus already carries every other tool call under an
|
||||
account whose permission list says what it may ask. Waiting would keep the one surface the mesh has
|
||||
from answering the mesh's own questions, for a reason that does not apply to it.
|
||||
|
||||
**2. Serve the verbs as the mesh-controller *module's* tools, `mesh.mod.mesh-controller.tool.<verb>`.**
|
||||
Rejected; 0132 rejected it already. The controller holds a seat, and the verbs must keep their address
|
||||
while the control plane is being replaced, which is the moment they are most needed. A module's name
|
||||
would change with the implementation; the seat's does not.
|
||||
|
||||
**3. Call each command's function inside the serving process.** Rejected on two facts: the commands
|
||||
print, to the process's standard output, and two calls answered at once would read each other's
|
||||
words; and each command opens and closes its own stores, which the serving process holds open. Making
|
||||
every command return a value is the larger refactor, and it would give the tools a second code path to
|
||||
keep in step with the command line — the thing ADR 0035 forbids.
|
||||
|
||||
**4. The holder of the seat runs the command it names, in its own binary, and answers what it
|
||||
printed.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**The `mesh-controller` seat serves twelve verbs**, and these are its interface, additive within a
|
||||
version ([33 — The tools the mesh answers](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md) §7):
|
||||
|
||||
| verb | answers with | takes |
|
||||
|---|---|---|
|
||||
| `tools` | every seat's tools, from the mesh's records | nothing |
|
||||
| `status` | what is wrong, quiet, behind, waiting — `status --json` | nothing |
|
||||
| `nodes` | every machine and its mode | nothing |
|
||||
| `node` | what one machine reported, what it is assigned, why | `node` |
|
||||
| `modules` | every module, its version, commit and machines | nothing |
|
||||
| `seats` | every seat, what it delivers, who holds it — `seats --json` | nothing |
|
||||
| `builds` | what was built lately and what came of it | `module` (optional) |
|
||||
| `plan` | the declaration a machine would be sent — `plan --json` | `node` |
|
||||
| `assign`, `unassign` | the mesh's own words, refusal included | `node`, `module` |
|
||||
| `push` | that it was sent; `status` says what the machine did | `node` (optional: every machine behind) |
|
||||
| `build` | that the build machine was asked; `builds` says what came of it | `repository`, `path`, `ref` |
|
||||
|
||||
**Each verb runs the command it names, in the controller's own binary, and answers what the command
|
||||
printed** — the output, whether it succeeded, and, where the command speaks JSON, the same as data. A
|
||||
refusal is the command's refusal in the command's words, because it is the same output. A verb takes
|
||||
only the arguments its schema names; nothing reaches a flag the schema did not declare. `push` and
|
||||
`build` are sent and not waited for: a call that blocked for a whole apply would time out on every
|
||||
machine that takes a minute and say nothing about the others.
|
||||
|
||||
**The three prerequisites are built.** A seat's protocol is three columns on its row, seeded from the
|
||||
compiled defaults where a row had none and additively thereafter, so a verb a release adds joins the
|
||||
row and nothing an operator wrote is taken away. A served verb is its name, what it does, and the
|
||||
schema of its arguments and answer; a manifest may still write a bare name. A node-scoped seat's tool
|
||||
carries the node it is asked of, as the last token of its subject; a mesh-scoped seat's stays flat.
|
||||
|
||||
**Holding a mesh seat requires serving its verbs**, judged where the store's set is loaded, and the
|
||||
refusal names the missing verbs. The controller's own manifest lists the twelve under `tools`.
|
||||
|
||||
**Discovery reads the records, through the seat.** `tools` is one of the twelve because the console
|
||||
cannot read the store and should not: the mesh answers for its own records through the role that owns
|
||||
them, and the answer is true while any *other* holder restarts. It is not true while the control plane
|
||||
itself restarts, and the console says so rather than hiding the modules' tools with it.
|
||||
|
||||
**A grant of `*` reaches a role's tools; `seat:<seat>.<verb>` grants one.** The console's `*` needed no
|
||||
change to reach the mesh's verbs, which is what a grant meaning *every tool* should mean.
|
||||
|
||||
> **The mechanism changed — 2026-10-02, by [ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md).**
|
||||
> The seat gains a generic verb beside the named ones: `command`, which takes one command line as the
|
||||
> controller's binary takes it and answers what it printed. The named verbs stand and keep their
|
||||
> schemas; `command` is the whole binary, added because the operator decided any node may call any
|
||||
> tool and a verb per command was the only thing keeping `node account`, `node show` and the rest
|
||||
> behind a shell on the control node. Additive within the version, as §"additive" above allows.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The console answers the mesh's own questions.** Issue 147's first paragraph closes: what a node
|
||||
runs, what is assigned, whether a push applied, from the machine the person sits at, over the bus,
|
||||
under an account whose permission list says so.
|
||||
- **Whoever may call `mesh-controller.push` may change the mesh.** That is the console's `*` on a
|
||||
machine whose login owns the mesh (0152), and a person's account only if `operator issue` says so.
|
||||
A grant reviewer reads `*` and `seat:mesh-controller.` with the same care.
|
||||
- **A verb here binds every future controller.** Twelve is deliberate: what an operator asks weekly,
|
||||
and nothing that is still finding its shape (`take`, `converge`, `settings`, `secret` stay commands).
|
||||
- **A command's text is the answer**, and text changes. The three verbs that speak JSON carry it as
|
||||
data; the rest are read by a person or an agent, not parsed. Anything that needs a shape asks for
|
||||
`--json` to be added to the command first, which is the right order.
|
||||
- **What got harder:** the mesh-controller seat's row now carries a protocol an operator could edit, and
|
||||
a verb removed from the row is a verb the controller stops serving without a build. That is
|
||||
ADR 0122's arrangement applied to tools, and `seats` shows the row.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| Every declared verb is one the binary can run, with the arguments its schema names | a test walks the table and derives a command line for each |
|
||||
| A verb missing a required argument is refused in its own words, before anything runs | a test per shape |
|
||||
| A holder that does not serve a mesh seat's verbs cannot hold it, and the refusal names them | a catalogue test against a seat with two verbs and a holder with one |
|
||||
| A node-scoped seat's tool carries the node; a mesh seat's does not | the bus composition test: two nodes derive two addresses |
|
||||
| The controller subscribes its seat's tools and may answer | the composition test, and the golden user list |
|
||||
| `*` reaches a role's tools; `seat:` grants one and refuses a name with no verb | the composition test |
|
||||
| The protocol is seeded into the row and widened additively | the store-backed seat test |
|
||||
| Live: the console lists `mesh-controller.status` and a call answers what `status --json` prints | the rollout of this record |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md) — extended: the prerequisites built, the verbs decided
|
||||
- [ADR 0152](0152-the-operators-surface-is-a-module-the-console.md) — the surface that lists them
|
||||
- [ADR 0035](0035-one-implementation-several-surfaces.md) — a surface is an adapter with no decisions in it
|
||||
- [ADR 0122](0122-a-seat-is-data-a-rename-is-a-database-update.md) — the row is the mesh's, and now carries the protocol
|
||||
- [33 — The tools the mesh answers](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md) — the design this completes
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-30
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0112-a-module-definition-names-no-node-mesh-or-path.md
|
||||
---
|
||||
|
||||
# 155. A definition names no installation: how that is checked, and the three ways a value that did gets out
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md) decided that a module definition
|
||||
names no node, no mesh and no host path, and said how the name half is checked: *a catalogue test
|
||||
finds no domain name in any definition value*. No such test existed
|
||||
([issue 134](../04-ISSUES/134-a-definition-may-still-name-the-mesh/00-report.md)). Written and run
|
||||
over the 77 definitions on 2026-09-30, the check it describes finds **42 values**, in 15 definitions,
|
||||
and they are of four kinds that want four different answers:
|
||||
|
||||
| kind | count | example |
|
||||
|---|---|---|
|
||||
| a service told its own public name as a literal | 5 | an identity provider's `KC_HOSTNAME`, an object store's console redirect, an automation tool's webhook URL |
|
||||
| an operator's value written into the definition | 10 | a mail server's domain, site name, website, and the address it trusts a real-IP header from |
|
||||
| this mesh's forge, by URL, as a recipe's build context | 2 | the builder and the proxy, which package the controller's source |
|
||||
| an application built outside the mesh, pulled from this mesh's registry | 7 | four sites and tools whose repositories are the operator's own |
|
||||
| the world's servers, named by upstream defaults | 10 | a Matrix homeserver's trusted key server, Element's integration manager |
|
||||
| a module named after the domain it serves | 8 | one site module, with its paths and network named after it |
|
||||
|
||||
Not one was careless. Each was the value the software needs, and until today there was nowhere else
|
||||
to put it ([issue 122](../04-ISSUES/122-a-module-cannot-ask-for-its-own-public-name/00-report.md)).
|
||||
Two of the answers were built before this record: a module is told the name its route composes
|
||||
(`${bound:<route>:name}`, controller PR 149, 2026-09-30), and a source may be a path on the git seat
|
||||
([ADR 0111](0111-a-build-source-is-on-the-git-seat-or-external.md)). What was missing: an operator's
|
||||
value in a file the software reads, the same for a build *context*, a way to say a name is meant, and
|
||||
the check.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. A string search for the installation's own names.** Rejected. The controller is as
|
||||
mesh-agnostic as the definitions; it does not know which names are "this mesh's", and a check that had
|
||||
to be told would be configured per installation and pass everywhere else. What it can know is the
|
||||
*shape*: a name under a public top-level domain, a public address.
|
||||
|
||||
**2. Report every such shape.** Rejected. Eight of the 42 were `why` strings — prose the mesh never
|
||||
reads, explaining what a port is for — and a check that reports those beside `KC_HOSTNAME` teaches
|
||||
people to ignore the report. And a Matrix homeserver *must* name the federation's public key server;
|
||||
a check with no way to say so would be a check people argue with rather than obey.
|
||||
|
||||
**3. Judge what the mesh acts on; let a definition say which names it means, one by one, with a
|
||||
reason; exempt the world's services that a definition may name as a policy default.** Chosen.
|
||||
|
||||
**For an operator's value**, one option was to wait for design 27's requirement form in full. Rejected
|
||||
for the reason 0112 gave against a slow operator provider: if asking a person for a value takes more
|
||||
than a setting, module authors route around it and the literals come back. `${setting:<key>}` is the
|
||||
operator provider in its first form, on the settings a module already has.
|
||||
|
||||
## Decision
|
||||
|
||||
**The check.** Every string value of a definition that the mesh acts on is judged for a hostname under
|
||||
a public top-level domain and for a public address. Not judged: `why` and `description`, which are
|
||||
prose. Allowed where they can only mean the world: the public registries an `image` may be pulled
|
||||
from, the public resolvers a machine may forward to, and the public certificate authorities' ACME
|
||||
directories. The container runtime's alias for its own host is the runtime's. A module's own name is a
|
||||
value too. The check runs in `module check` and as a catalogue-wide test; **it does not yet refuse at
|
||||
registration**, because the list it prints is the list that shrinks, and a registration that refused a
|
||||
manifest whose only remedy is a merge elsewhere would refuse the mesh's own catalogue on the day the
|
||||
check landed. It moves to registration when the list has been empty for a release.
|
||||
|
||||
> **Progressive insight — 2026-09-30.** The list was empty the day the check landed — every remaining name declared with its reason — and the operator asked for registration to refuse at once rather than after a release. It does, since mesh-controller PR 175: `module add` and a build's result are refused in the check's words, naming the way out, and the build stays recorded. The decision stands; only the day moved.
|
||||
|
||||
**A name a definition means is declared with its reason.** `names-on-purpose` on a resource maps each
|
||||
such name to why: *the federation's public key server, the world's*; *built outside the mesh, from the
|
||||
application's own repository, until that repository is a build source on the git seat*. A name the map
|
||||
does not cover is still reported. The host never sees the word.
|
||||
|
||||
**An operator's value reaches a file as `${setting:<key>}`**, filled from the module's settings
|
||||
layers — the mesh's, then the node's — the same layers a mergeable file and a contribution take, so
|
||||
`settings set <module>` stays the one place a person's values go. Refused, naming the key and the
|
||||
command, when nothing set it: a default for a mail domain would be the literal this removes, and a
|
||||
blank written silently would be a service that comes up wrong somewhere that names nothing.
|
||||
|
||||
**A build context may live on the git seat.** `context: {"seat": "git", "repository": "<owner>/<name>"}`
|
||||
is composed by the mesh that builds it: the request carries each seat's clone base, and a builder told
|
||||
no base for a seat a context names refuses the build by the seat's name rather than guessing a forge.
|
||||
|
||||
**A module is named for what it is.** The site module named after its domain is `website`.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The catalogue names no installation, and a test says so.** The forty-two became zero the same day,
|
||||
by the four answers above; seven of them are declared on purpose and stay visible as the list to
|
||||
shrink — four applications the mesh does not build yet.
|
||||
- **An operator's values are the assignment's.** The mail module takes its domain, its site name, its
|
||||
website and the address it trusts a real-IP header from as settings; a mesh that installs it without
|
||||
them is refused at composition, by name, which is the right moment. The module's own README says
|
||||
which.
|
||||
- **What got harder:** a manifest reviewer has one more word to read, and `names-on-purpose` on an
|
||||
application's image is a debt visible in the definition until the application is built here. A
|
||||
reader of `settings set` output sees more keys than files, because a key a file asks for is a
|
||||
destination too.
|
||||
- **Not decided here:** ADR 0112's requirement form (design 27) still replaces `${setting:…}` and the
|
||||
other placeholders when it lands; this is its first case, the way [ADR 0038](0038-the-mesh-assigns-the-port.md)
|
||||
was for ports. Host paths ([issue 119](../04-ISSUES/119-a-module-definition-decides-where-its-files-live/00-report.md))
|
||||
are the next step of the same group, and the registry's name ([issue 123](../04-ISSUES/123-the-image-registry-is-named-after-a-role/00-report.md))
|
||||
the one after.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A value naming an installation is reported at its path, in the definition's words | a catalogue unit test over a definition with a hostname in an env value and a public address in a file |
|
||||
| Prose, the world's registries in an image, public resolvers, ACME directories and the runtime's own alias are not reported | the same tests |
|
||||
| A name declared on purpose is not reported; a name beside it that is not declared is | a test with a homeserver's config |
|
||||
| An image from an installation's registry needs a reason | a test without and with the word |
|
||||
| A module named after a domain is reported | a test |
|
||||
| No definition in the catalogue names an installation | `TestNoCatalogueManifestNamesAnInstallation` over the checkout, and `module check modules/` |
|
||||
| A definition naming an installation is refused at registration, and one declaring its names passes | `TestRegistrationRefusesADefinitionNamingAnInstallation` (2026-09-30) |
|
||||
| `${setting:key}` fills from the layers, node over mesh; refused by name when unset; not stray when set | three tests |
|
||||
| A context on a seat is cloned from the base the mesh sent; a seat with no base is refused by name | the builder's test |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md) — extended: the check it promised, and the operator provider's first form
|
||||
- [ADR 0111](0111-a-build-source-is-on-the-git-seat-or-external.md) — a source on the seat; now a context too
|
||||
- [issue 122](../04-ISSUES/122-a-module-cannot-ask-for-its-own-public-name/00-report.md), [issue 134](../04-ISSUES/134-a-definition-may-still-name-the-mesh/00-report.md) — what this closes
|
||||
- [27 — A module requires, the mesh resolves](../03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md) — where this sits in the larger design
|
||||
- mesh-controller PR 169, mesh-catalog PR 188 — the check, the words, and the catalogue that passes it
|
||||
+83
@@ -0,0 +1,83 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-09-30
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0075-two-stores-and-which-provides-what.md
|
||||
---
|
||||
|
||||
# 156. An artifact is what a build produces, the artifact store serves every kind, and its seat is named for its scope
|
||||
|
||||
## Context
|
||||
|
||||
[Issue 123](../04-ISSUES/123-the-image-registry-is-named-after-a-role/00-report.md) found three
|
||||
wordings disagreeing about the mesh's registry. The glossary defined *artifact* as "an OCI image, by
|
||||
digest"; the manifest's build vocabulary names four kinds — `image`, `upstream`, `bundle`, `archive` —
|
||||
and the catalogue builds all four; the seat was `the-artifact-store`, the last of the mesh's own seats
|
||||
named after the job it does rather than for the mesh
|
||||
([ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md) decided the
|
||||
rename and deferred it). The issue asked whether the seat and provision should be renamed after
|
||||
images, and whether the mesh needs two registry implementations at all.
|
||||
|
||||
Reading what the store actually serves settles the first question the other way. A kept reference
|
||||
has two shapes — `artifact-store://<module>/<artifact>@sha256:…` for an image and
|
||||
`artifact-store://<module>/<artifact>/blobs/sha256:…` for an archive — and both are served by the
|
||||
same OCI registry, by digest. [ADR 0075](0075-two-stores-and-which-provides-what.md) already
|
||||
defined the provision that way: *content-addressed blobs, pinned by digest, no versions, no ranges;
|
||||
what the mesh delivers to machines*. The provision was never an image registry. Only the glossary said
|
||||
so, and only the seat's name was odd.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. Rename the seat and the provision after images.** Rejected. The store serves archives too, by the
|
||||
same protocol; naming it for one kind would be the glossary's mistake made permanent, in the name
|
||||
every manifest uses.
|
||||
|
||||
**2. Fix the word, rename the seat for its scope, keep the provision.** Chosen. The rename ADR 0121
|
||||
deferred as a delivering-seat migration is, since [ADR 0122](0122-a-seat-is-data-a-rename-is-a-database-update.md),
|
||||
one update and one alias: the former name resolves forever, a held record follows by cascade, a claim
|
||||
written with the old name still holds.
|
||||
|
||||
**On two implementations:** left as 0075 decided. Two provisions because two protocols; the OCI
|
||||
registry the genesis installs because something must serve images before the mesh can build; the
|
||||
forge may provide `artifact-store` too and a mesh may choose it. The bootstrap argument is weaker than
|
||||
it reads, as 123 says, and the day the forge is raised at genesis and adopted in place is the day to
|
||||
retire the second server — a migration a mesh performs, not a decision to take here.
|
||||
|
||||
## Decision
|
||||
|
||||
- **An artifact is anything a build produces** — an image, a mirrored upstream image, a bundle, an
|
||||
archive — and the glossary says so. *Image* is one kind. A module is not an image; a module may
|
||||
build several artifacts and install none.
|
||||
- **The artifact store serves artifacts of every kind a machine fetches**, images and archives, by
|
||||
digest, over the OCI registry protocol. The provision keeps its name.
|
||||
- **The seat is `mesh-artifact-store`.** `the-artifact-store` is its alias. The catalogue's registry
|
||||
module claims the new name; a definition elsewhere claiming the old one still holds.
|
||||
- The two other deferred renames — `npm-package-registry` and `git` — stay deferred, and for the
|
||||
same reason no longer. They are one migration each when wanted; nothing here needs them.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The glossary stops contradicting the manifest vocabulary, and a reader of `artifact-store` reads
|
||||
it as what it is: where the mesh's built things are kept.
|
||||
- One migration on the seat table; no manifest but the registry's changes; no consumer of the
|
||||
provision changes, because the provision did not.
|
||||
- **What got harder:** nothing measurable. A record that says `the-artifact-store` is read through the
|
||||
alias; design 26's table already carried the new name as intent.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| The former name resolves to the seat once the store's aliases are loaded | a catalogue test |
|
||||
| The seat is in the compiled set under its new name, delivering `artifact-store` | the seat tests, updated |
|
||||
| The registry module holds the seat under the new name on the live mesh | `seats` after the rollout |
|
||||
| The glossary's *artifact* matches the build kinds a manifest may declare | design 18's table and the showcase module list the kinds; the glossary names the same four |
|
||||
|
||||
## References
|
||||
|
||||
- [issue 123](../04-ISSUES/123-the-image-registry-is-named-after-a-role/00-report.md)
|
||||
- [ADR 0075](0075-two-stores-and-which-provides-what.md) — extended: the provision as defined stands, the word is corrected
|
||||
- [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md), [ADR 0122](0122-a-seat-is-data-a-rename-is-a-database-update.md) — the rename, decided and made cheap
|
||||
- mesh-controller migration 0048; mesh-catalog `modules/distribution`
|
||||
@@ -0,0 +1,99 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md
|
||||
---
|
||||
|
||||
# 157. A build says what it does on the bus, as it happens
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md) made a build work submitted to a role: the
|
||||
build-machine seat accepts a build and emits its outcome, one publish that reaches whoever asked, the
|
||||
controller that records it and the catalogue that places it. Everything **between** the request and
|
||||
the outcome — which command is running, how long it has taken, where it hung, the compiler's error,
|
||||
the clone's refusal — lived in one container's standard error on one machine.
|
||||
|
||||
The night of 2026-09-30 showed the cost three times over. A build that failed showed a person one
|
||||
line, the first of its failure, in the controller's `builds`; the rest was read with `docker logs` over
|
||||
ssh, which the mesh's own rule forbids. A build that ran for minutes could not be told from one that
|
||||
had hung. And the builder has no tools and emits nothing but the outcome, so the console
|
||||
([ADR 0152](0152-the-operators-surface-is-a-module-the-console.md)) had nothing to show while a
|
||||
build ran, and no viewer could be built on top of it. The operator's ask was plain: the builder is to
|
||||
be fully transparent, with its log on the bus, so that a log viewer can be built on the bus later.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep the log in the outcome.** The result carries the whole log when the build ends. Nothing new
|
||||
on the bus; nothing while the build runs; a viewer sees a build only once it is over, which is
|
||||
exactly when the log matters least.
|
||||
2. **A log store.** The builder writes its log to a file or a table and a tool reads it. A second
|
||||
place to keep something the bus already carries, with its own retention, access and failure modes,
|
||||
and no live reading without inventing a subscription over it.
|
||||
3. **The log is the role's own events.** Two more events on the build-machine seat beside `built`:
|
||||
`started` when work is taken, and `log.<build id>` for every line, published as the build runs.
|
||||
The events stream already retains every role's events for a week, so a reader follows a build
|
||||
live by subscribing its subject, or reads it back afterwards from the stream, and a viewer is a
|
||||
subscriber and nothing more.
|
||||
|
||||
## Decision
|
||||
|
||||
**Option 3.** A build machine says everything it does on the bus, as the role it holds, under the
|
||||
build's id, and the mesh keeps no other copy.
|
||||
|
||||
- The build-machine seat's protocol gains `started` and `log.*`. A holder may therefore publish
|
||||
`mesh.seat.mesh-build-machine.event.started` and `…event.log.<id>`, and no other subject, by the
|
||||
same derivation every seat's grants follow ([ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md)).
|
||||
The event's tail token is the build's id, so one build is one subject: a reader filters by subject
|
||||
alone, on the server, and a week of other builds does not travel to show one.
|
||||
- **Every line goes two ways**: to the machine's own standard error as before, and onto the bus. That
|
||||
includes every command the builder runs, its duration and its failure, and on failure the command's
|
||||
own output line by line — the compiler's words, the clone's refusal. A build machine with nobody
|
||||
listening still prints; a listener reads the same lines.
|
||||
- A line is a core publish, unawaited. The stream that holds the role's events captures it on its way
|
||||
through, and a build does not slow to the pace of an acknowledgement per line. Each line carries a
|
||||
sequence number from one, so a reader who joined late, or reads two copies, sees order and gaps.
|
||||
`started` and `built` are published into the stream and awaited, because they are the two facts a
|
||||
later reader must never find missing.
|
||||
- **The mesh reads it back from the stream**, never from a record of its own: `builds --log <id>`, and
|
||||
the same verb on the controller's seat ([ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md)),
|
||||
reads one build's subject with a consumer that is gone when the reading is done. `builds` lists
|
||||
each build's id beside it, and `build` says the id it asked with, so a person can follow.
|
||||
- Nothing is declared by the builder module for this. The protocol is the seat's, seeded additively
|
||||
into the store ([ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md)), and the
|
||||
holder's grant follows on the next composition of the broker node.
|
||||
|
||||
## Consequences
|
||||
|
||||
- A build is watchable while it runs, from anywhere on the mesh, with no access to the build machine.
|
||||
The console's gap of 2026-10-01 — no live progress, no per-merge view — closes on the progress half;
|
||||
the per-merge view is a reader over these subjects and the outcome, and is not built here.
|
||||
- A log viewer on the bus is now a plain subscriber: live on `mesh.seat.mesh-build-machine.event.>`,
|
||||
historical from the events stream filtered by a build's subject. NATS carries and retains; it does
|
||||
not view. The `nats` command-line client can tail or replay a subject today; a viewer of our own is
|
||||
later work and needs nothing more from the builder.
|
||||
- The events stream grows by a build's log per build, for a week. A build is a few hundred lines; the
|
||||
stream's limits are the bound, as for every other event, and a stream that fills drops the oldest.
|
||||
- A line the bus did not take is lost, deliberately, and visible as a gap in the sequence. The outcome
|
||||
is not affected: a build's result never depended on its narration.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| The seat's holder may publish `started` and `log.<id>` and nothing wider | `TestTheBuildMachineMaySayWhatItDoesUnderTheBuildsId` (broker) |
|
||||
| A build's lines reach a reader of its subject in order, and the stream holds them afterwards | `TestNatsABuildIsTakenAndItsOutcomeReachesEverybody` against a real server (link) |
|
||||
| The seat verb `builds` with a build's id reads that build's log | `TestBuildsWithAnIdReadsThatBuildsLog` |
|
||||
| Every command the builder runs is said, with its output on failure | `Command` speaks through the hook every build sets; the builder's tests still see the lines on standard error when nothing listens |
|
||||
| Live: a build triggered after the roll-out is readable line by line through the console | done by hand after the merge of mesh-controller PR — see the design's note |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md) — extended: the role now narrates as well as answers
|
||||
- [ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md), [ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md) — the protocol and the verb
|
||||
- [ADR 0152](0152-the-operators-surface-is-a-module-the-console.md) — the console this feeds
|
||||
- [Design 25 — The bus on NATS](../03-DESIGN/01-to-be/25-the-bus-on-nats.md) §3, [Design 18 — Building a module](../03-DESIGN/01-to-be/18-building-a-module.md)
|
||||
- [Issue 176](../04-ISSUES/176-the-consoles-build-tool-neither-waits-nor-registers/00-report.md) — the tool that starts a build and hears nothing; this gives it something to hear
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0048-a-provider-creates-the-credential-the-mesh-minted.md
|
||||
---
|
||||
|
||||
# 158. A provider with one credential shares it with every consumer, and the vault remakes it for all of them at once
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0048](0048-a-provider-creates-the-credential-the-mesh-minted.md) gave every consumer of a
|
||||
provision its own credential: the mesh mints one per pair, the provider's own code creates the
|
||||
login, and rotating one consumer's touches nothing else. That is right for a database, a broker, an
|
||||
object store — software that can hold many logins.
|
||||
|
||||
The media software on the home server cannot. A download client has one web password; an indexer
|
||||
has one API key; each of the library managers has one key in its configuration; the media server
|
||||
holds one token issued elsewhere. There is no login per consumer to create, so
|
||||
[ADR 0113](0113-the-vault-makes-every-secret.md)'s only remaining form applied: the value is
|
||||
*accepted*. On 2026-10-01 the home server held forty-seven accepted own secrets and twelve accepted
|
||||
pair credentials, every one rotatable only by a person changing the software by hand and accepting
|
||||
the new value, and one pair credential sat *made* and wrong because nobody could accept the real one.
|
||||
The operator asked for every password in the vault and rotatable, and for a library manager's
|
||||
definition to receive the download client's credential and address through provisioning like
|
||||
anything else (filed as the forge's issue 243 on this repository).
|
||||
|
||||
The address half already works: the library manager requires the download client's API provision,
|
||||
the provider serves scheme, port and user name, and the binding carries them. Only the credential
|
||||
half had no form.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep accepting.** Honest about what the software can do and what the mesh cannot, and it is
|
||||
the state the home server was in: nothing rotates, a consumer added later needs a person, and an
|
||||
unknown predecessor password stays unknown for ever.
|
||||
2. **Put a login per consumer in front of the software.** A proxy that holds the one credential and
|
||||
issues many. A second service per provider, with its own credential to keep, to make the mesh's
|
||||
model fit software that does not share it.
|
||||
3. **Let the provider say its one credential is the credential.** An offer names which of the
|
||||
provider's own secrets *is* what every consumer receives. The vault keeps one record, sealed to
|
||||
the provider's machine, every current consumer's machine and the operator, and because it stores
|
||||
no plaintext it cannot seal an existing value to a later consumer — so it **remakes the value
|
||||
for all of them at once** whenever the set of consumers changes or a rotation is asked. The
|
||||
provider takes it the way an own secret is taken ([ADR 0114](0114-a-shared-credential-rotates-over-two-credentials.md),
|
||||
issue 180); consumers read it at start.
|
||||
|
||||
## Decision
|
||||
|
||||
**Option 3.** A provider whose software holds one credential shares that credential, and the mesh
|
||||
owns its whole lifecycle.
|
||||
|
||||
- **The offer says so.** `{"name": "download-client-api", "credential": {"own": "password"}}` on a
|
||||
provider's `provides` entry names one of its own secrets as the credential of that provision. The
|
||||
named own secret must say how it is taken (`taken: at-start` or `taken: applied`); an offer
|
||||
naming an undeclared or untaken secret is refused at parse.
|
||||
- **One record, many seals.** The vault keeps one value per (provider assignment, provision). It is
|
||||
sealed to the provider's machine, to each consumer's machine that currently binds the provision,
|
||||
and to the operator. Every consumer's binding file carries the provider's one user name and the
|
||||
secret file carries the shared value; the shape a consumer reads is the pair credential's, so a
|
||||
consumer's definition does not know whether its credential is shared.
|
||||
- **Remade for all, together.** When a consumer binds or unbinds, or `secret rotate` is asked on the
|
||||
provider's own secret, the vault makes a new value and seals it to every current holder in one
|
||||
act, and the mesh sends every holding machine. The provider restarts on the new value or applies
|
||||
it at start; each consumer restarts on it. There is no window between two credentials, because
|
||||
there is one credential; there is the restart, stated as the cost below.
|
||||
- **An accepted shared value is sealed to everyone the moment it is accepted.** `secret accept` on
|
||||
the provider's own secret is the one moment the mesh holds the plaintext, and it seals copies for
|
||||
every current consumer then. It is not remade afterwards ([ADR 0113](0113-the-vault-makes-every-secret.md)):
|
||||
a consumer that binds later is refused until the value is accepted again, in words that say so.
|
||||
- **A value the software issues itself stays accepted.** A token the media server obtains from its
|
||||
vendor cannot be set by the mesh; its provision keeps the accepted form until a module can deliver a
|
||||
value it did not mint to the vault, which this record does not build.
|
||||
- **Nothing changes for software that holds many logins.** ADR 0048's form stays the default; this
|
||||
is the form for an offer that says it has one credential.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The media stack's six providers stop needing a person per consumer. A library manager binding
|
||||
the download client gets a working credential the mesh made, and an unknown predecessor password
|
||||
is replaced by one the mesh knows, recoverable with the operator's key.
|
||||
- **Adding or removing a consumer restarts every consumer of that provision and the provider.**
|
||||
That is the price of one credential, and it is paid when a definition binds, not at an hour of
|
||||
nobody's choosing. It is stated in the plan's words when it happens.
|
||||
- Rotation of a shared credential is [ADR 0114](0114-a-shared-credential-rotates-over-two-credentials.md)'s
|
||||
single-party form across several machines: in place, all holders sent together. The staged form
|
||||
for a backend that takes its credential once is still not built, and a provider whose own secret
|
||||
says `applied` refuses rotation by name until it is.
|
||||
- The vault can name who holds a shared value — the copies are the record — so *who has this* stays
|
||||
a query, as design 13 requires.
|
||||
- The accepted count on the home server becomes a list that shrinks, provider by provider, as each
|
||||
one's start applies the file.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| An offer may name one of its own secrets as its credential; an undeclared or untaken secret is refused at parse | manifest tests |
|
||||
| A consumer of a shared provision receives the provider's value as its pair credential, under the provider's one user name | resolver and declaration tests |
|
||||
| The record is sealed to the provider, every current consumer and the operator; a consumer binding or unbinding remakes it for all | inventory tests against a raised store |
|
||||
| Rotating the provider's own secret remakes every holder's copy, and an accepted value is sealed to current consumers once and not remade | inventory tests |
|
||||
| Live: a library manager on the home server binds the download client with a value the mesh made, the client takes it at start, and a rotation through the console reaches both | done by hand after the media catalogue's providers apply the file at start |
|
||||
|
||||
*2026-10-01:* the first four rows pass in mesh-controller PR 184 (`make check` green); the live row waits for the first provider definition to say `credential` and `taken`.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0048](0048-a-provider-creates-the-credential-the-mesh-minted.md) — extended: the per-consumer form stays the default; this is the form for one credential
|
||||
- [ADR 0113](0113-the-vault-makes-every-secret.md), [ADR 0114](0114-a-shared-credential-rotates-over-two-credentials.md) — the accepted form and the single-party rotation this rests on
|
||||
- [Issue 180](../04-ISSUES/180-a-modules-own-secret-cannot-be-rotated/00-report.md) — the `taken` word and the rotation this reuses
|
||||
- [Design 24 — The secrets vault](../03-DESIGN/01-to-be/24-the-secrets-vault.md), [Design 13 — Credentials and their rotation](../03-DESIGN/01-to-be/13-credentials-and-their-rotation.md)
|
||||
- The forge's issue 243 on this repository, where the operator's ask and the home server's count were recorded
|
||||
+99
@@ -0,0 +1,99 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0152-the-operators-surface-is-a-module-the-console.md
|
||||
---
|
||||
|
||||
# 159. A tool call names the machine it is for, every answer says which machine answered, and a holder's runtime serves its seat's verbs
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0152](0152-the-operators-surface-is-a-module-the-console.md) made a module's tools subjects on
|
||||
the bus and the console the place a person reaches them. [ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md)
|
||||
made the mesh's own verbs the controller seat's tools, served by the controller. Design 33 said what
|
||||
a seat's tools are, that holding a seat means serving them, and that a node-scoped seat's verb
|
||||
carries the machine.
|
||||
|
||||
What was built stopped short in two places ([issue 182](../04-ISSUES/182-a-tool-call-reaches-whichever-instance-answers-first/00-report.md)).
|
||||
A module's tools were one subject per module in one queue group, so with the database engine on two
|
||||
machines a call reached whichever instance answered first, unnamed, and nobody could ask one machine's.
|
||||
And no module served the verbs of a seat it held: the runtime did not know which seats its module
|
||||
claimed, and no seat but the controller's declared verbs. The operator named it: a tool call must be
|
||||
able to say *the store on the control node*, and the engine holding the store seat must serve the
|
||||
store's tools as well as its own.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Leave the queue group and ask the controller which machine answered.** Nothing changes on the
|
||||
bus; a caller cannot choose, only learn afterwards. Useless for the question that was asked.
|
||||
2. **A subject per machine instead of one per module.** Every call names a machine; a stateless
|
||||
module on three machines loses the one-of-them answer a queue group gives for free, and every
|
||||
caller has to know where things run.
|
||||
3. **Both subjects, and the machine in every answer.** An instance serves its module's subject in the
|
||||
queue group as before, and the same subject with its machine as the last token. A caller that
|
||||
names no machine gets one instance and is told which; a caller that names one gets that one. The
|
||||
grant for a tool covers both. And a holder's runtime serves its seat's verbs by the same means,
|
||||
from what the credential tells it.
|
||||
|
||||
## Decision
|
||||
|
||||
**Option 3.**
|
||||
|
||||
- **Two subjects per tool, one default.** `mesh.mod.<module>.tool.<tool>` in the queue group, and
|
||||
`mesh.mod.<module>.tool.<tool>.<node>` served by the instance on that machine alone. In the
|
||||
caller's words, `<module>.<tool>@<node>`. A runtime that does not know its machine serves only the
|
||||
first, which is what it always did.
|
||||
- **Every answer says which machine answered.** The reply carries the node; the console appends
|
||||
*answered by <node>* as its own line after the module's unshaped answer, and `mesh call` prints it.
|
||||
An answer from a module on several machines is never an answer from nowhere.
|
||||
- **The console offers the machine on every module tool** as an optional `node` argument, lists it,
|
||||
strips it into the subject and never passes it to the module. A seat's verb takes none: the seat's
|
||||
scope decides where it is served.
|
||||
- **The grant covers both subjects.** `invokes: [<module>.<tool>]` permits the plain subject and the
|
||||
machine-addressed one; `*` already permitted everything beneath `tool`.
|
||||
- **A holder's runtime serves its seat's verbs.** The broker credential the mesh writes names the
|
||||
seats the module claims and, for each, its scope and the verbs the seat promises. The runtime
|
||||
serves each verb with the module's tool of the same name on the seat's own subject — flat for a
|
||||
mesh seat, with the machine for a node-scoped one — and the bus admits that subscription only
|
||||
where the module holds the seat, because the holder's grant is composed from the holding. A
|
||||
claimant that does not hold the seat here is refused the subscription and serves nothing. A
|
||||
claimant missing a tool a seat promises is already refused at registration (design 33 §3).
|
||||
- **The store seat's first verbs**, so the operator's question has an answer: `databases`, every
|
||||
database the store holds with its owner and size, and `query`, one read-only statement against one
|
||||
database. The database engine serves both as tools of those names and lists them in its definition.
|
||||
Which verbs a seat serves is a decision per seat and binds every holder; these two are the smallest
|
||||
set that makes the store askable.
|
||||
|
||||
## Consequences
|
||||
|
||||
- *List the databases of the store on the control node* is `mesh-store.databases` through the seat,
|
||||
answered by its holder wherever it sits, or `postgres.databases@novox` through the module on one
|
||||
named machine. Both say who answered.
|
||||
- Every module's runtime serves one more subscription per tool and, for a claimant, one per promised
|
||||
verb. No manifest changes for the per-machine half; the seat half needs each holder's definition to
|
||||
list the seat's verbs among its tools, which registration already demands.
|
||||
- The runtime change reaches a module when the module is rebuilt on the new runtime image; until
|
||||
then that module answers only on its plain subject, and a call naming its machine is refused as
|
||||
unserved, in words that say so.
|
||||
- The credential gains `claims`; a module issued before this carries none and serves no seat verb
|
||||
until it is issued again. `rollout mint` for the holders is the one-time cost.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A call naming a machine reaches that machine's instance; an unnamed call reaches one and says which | mesh-tools, against a real bus: a module on two machines |
|
||||
| A claimant serves a seat's verb on the seat's subject, and the answer names the machine | the same test |
|
||||
| The console lists `node` on a module's tool and not on a seat's verb, and the answer carries *answered by* | mesh-tools, the MCP conformance test |
|
||||
| The grant for a tool covers the plain and the machine-addressed subject | `TestInvokingAToolMayAddressTheMachineToo` (controller) |
|
||||
| Live: the store's databases listed from the control node by name through the console, and through the store seat | done by hand after the roll-out and the catalogue's step |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0152](0152-the-operators-surface-is-a-module-the-console.md) — extended: the surface carries the machine
|
||||
- [ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md), [ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md) — the seat half, now for every holder
|
||||
- [Design 33 — The tools the mesh answers](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md) §3, §4; [Design 34 — The console](../03-DESIGN/01-to-be/34-the-console.md) §3
|
||||
- [Issue 182](../04-ISSUES/182-a-tool-call-reaches-whichever-instance-answers-first/00-report.md)
|
||||
+139
@@ -0,0 +1,139 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md
|
||||
---
|
||||
|
||||
# 160. The mesh issues an assignment's subjects, and a runtime serves what it is issued
|
||||
|
||||
## Context
|
||||
|
||||
A module's code names no subject. It registers tools by name and emits events by name, and design 29
|
||||
§1 says the rest: *the module names its event and the mesh decides where it lands*. What was built
|
||||
decided it twice. The runtime derives `mesh.mod.<module>.tool.<name>` from the module's name by a rule
|
||||
compiled into it; the controller derives the same subject by the same rule compiled into it, and grants
|
||||
it. They agree because two binaries carry one convention, which is the failure design 33 §2 names for
|
||||
seat protocols: *discovery that reads a binary disagrees with the mesh the moment the two are on
|
||||
different versions*. [ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md)
|
||||
extended the convention this morning — a second subject per tool with the machine as its last token, a
|
||||
seat's verbs served from the credential's claims — and extending it made the shape plain: every such
|
||||
change is written in the runtime and in the controller, and a module whose instances must not be
|
||||
confused is told apart by a rule in a binary rather than by the mesh that assigned it.
|
||||
|
||||
The operator put it in one sentence: the mesh knows the subjects, the modules do not; a module should
|
||||
ask what to listen on. This record decides exactly that.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep the convention, keep it in two places.** Cheap until the next change; every change is two
|
||||
changes, and the mesh cannot vary a subject for one assignment without a rule for all.
|
||||
2. **Keep the convention in one place by putting it in the SDK alone**, and have the controller call
|
||||
the SDK's rule. The controller is Go and the SDK is TypeScript; one of them would still carry a copy.
|
||||
3. **The mesh issues the subjects.** For every assignment the controller composes a membership: what
|
||||
this instance serves, where, in which queue if any; the seat verbs it holds; where its events land;
|
||||
what it may reach and at which subjects. It publishes it to a subject only that assignment may read,
|
||||
kept last-per-subject so a runtime that connects late reads the current one. The runtime serves
|
||||
exactly the list and nothing it did not receive. The grant is composed from the same membership, in
|
||||
the same act, so the two cannot drift.
|
||||
|
||||
## Decision
|
||||
|
||||
**Option 3.**
|
||||
|
||||
- **A membership per assignment.** The controller composes, for a module on a machine, one document:
|
||||
the tools the module serves with the subject each is served on and the queue group if any; the seat
|
||||
verbs this instance serves and their subjects; the subject each of its events lands on; what it may
|
||||
reach — the tools it invokes, resolved to the subjects the mesh issued to those modules' instances —
|
||||
and what it consumes. The runtime registers tools and events by name; the membership says where.
|
||||
- **Published, not written into the definition.** The membership is a message on
|
||||
`mesh.assignment.<node>.<module>` in a stream that keeps the last per subject, like a node's
|
||||
declaration. The controller publishes it whenever the assignment's facts change: a push, a seat
|
||||
handover, an instance added elsewhere, an upgrade. A runtime reads the current one when it connects,
|
||||
serves it, and keeps reading, so a change reaches a running instance as a re-subscription rather
|
||||
than a restart.
|
||||
- **One bootstrap rule, and only one.** The credential names the node and the module; the membership's
|
||||
subject follows from those two names and nothing else, and the account may subscribe it. Every
|
||||
other subject is data in the membership. This is the one convention the runtime keeps, the way a
|
||||
resolver keeps the address of a root.
|
||||
- **The grant is the membership, read the other way.** What an account may subscribe is what its
|
||||
membership says it serves plus its own membership's subject; what it may publish is what its
|
||||
membership says it emits and reaches. One composition yields both, so a subject the runtime serves
|
||||
without a grant, or a grant for a subject nothing serves, cannot be written.
|
||||
- **Whether an instance answers for the module, or only for its machine, is the mesh's to decide.**
|
||||
A module on one machine is issued the module's plain subject and its machine's. A module on several
|
||||
is issued only its machine's unless its definition says its instances are interchangeable, a fact
|
||||
about the software and not about the bus; then every instance is issued the plain subject in one
|
||||
queue group as well. The console lists what the memberships say: a stateful module on two machines
|
||||
appears once per machine; a stateless one appears once.
|
||||
- **A caller composes nothing.** The console's listing carries each tool's subject; the SDK's call by
|
||||
name reads the subject from the caller's own membership, where the mesh wrote what it may reach. The
|
||||
shape of a subject is the controller's business and may change without any module or runtime
|
||||
changing.
|
||||
- **Today's shape is the shape issued first.** `mesh.mod.<module>.tool.<name>`, with the machine as the
|
||||
last token for an instance, and `mesh.seat.<seat>.tool.<verb>` with the machine for a node-scoped
|
||||
seat, are what the controller composes on day one, so nothing on the mesh moves when the
|
||||
membership arrives; only who decides it moves. [ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md)
|
||||
stands for what it decided — a call names the machine, every answer names it, a holder serves its
|
||||
seat — and is extended in how: those facts are now issued, not derived.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The runtime loses its subject rule and its claims rule; it serves a list. The controller gains one
|
||||
composition and one stream; design 25 §2 and §3 gain a line each. The console loses `toolSubject`
|
||||
and reads subjects from the listing. The SDK's `invokeTool` reads the caller's membership.
|
||||
- A subject scheme change is a controller release and a republish of every membership, with no module
|
||||
rebuilt — the opposite of this morning's forty-three builds.
|
||||
- A membership can differ per assignment on purpose: an instance that holds a seat serves more; an
|
||||
instance the mesh wants quiet serves less; a module the mesh is retiring can be issued nothing and
|
||||
told so.
|
||||
- During the move, a runtime that finds no membership for its assignment falls back to the derived
|
||||
shape and says so in its log, so the wave of this change is a controller release followed by one
|
||||
push, and a runtime older than the change keeps working on the convention it carries.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A membership composed for an assignment and the grant composed for its account name the same subjects, both ways | a controller test over a module on one machine, on two, holding a seat, and declared interchangeable |
|
||||
| A runtime serves exactly the subjects its membership lists, and re-subscribes when the membership changes | a runtime test against a real bus: a membership published, served; republished with a subject removed and one added, followed |
|
||||
| A runtime with no membership says so and serves the derived shape | the same test, before any membership is published |
|
||||
| The console lists a stateful module on two machines once per machine, and composes no subject | the MCP conformance test |
|
||||
| Live: the store's databases asked of one named machine and through the seat, after a controller release and one push, with no module rebuilt | by hand |
|
||||
|
||||
## Built, 2026-10-01
|
||||
|
||||
> **Progressive insight — 2026-10-01.** The decision stands; these are the facts of its building.
|
||||
|
||||
- The controller's half: mesh-controller 188 — the membership, its subject, the assignments stream
|
||||
read directly, a module's account granted its own membership and nothing else of the stream, a
|
||||
membership published after each push.
|
||||
- The runtime's half: mesh-tools 23 — the one address derived, the membership read and followed,
|
||||
exactly the issued subjects served and re-served, the derived shape with a log line until one is
|
||||
issued, a seat's verbs implemented under the seat's name and never listed as the module's, the
|
||||
listing carrying subjects and the console composing none. A claim may now name the verbs it
|
||||
serves for its seat (mesh-controller 186), so a holder's own tools need not be the seat's.
|
||||
- What the first roll-out taught: the controller's own grant did not name the assignments it issues,
|
||||
so the first memberships were refused by the server and every runtime kept the derived shape —
|
||||
which is exactly the fallback this record asked for, and exactly why nobody noticed
|
||||
([issue 183](../04-ISSUES/183-the-controller-could-not-publish-the-memberships-it-issued/00-report.md)).
|
||||
The SDK's `invokeTool` still composes a subject; it reaches a membership through the runtime's
|
||||
broker, which does, so the caller-side rule is met there and not yet in the SDK's own words.
|
||||
- Live, 14:55Z the same day, through the console: the console's runtime logged *was issued a new
|
||||
membership; re-serving on it*; `mesh-store.databases` answered by the control node, the seat's
|
||||
holder; `postgres.postgres_list_databases` with the machine named answered by that machine, on
|
||||
both machines that run it; `mesh-controller.push {node}` reached the seat's verb with its own
|
||||
argument intact. Three facts the proof taught: a runtime's first read of the stream must use the
|
||||
subject-addressed direct get, the only form its account is granted (mesh-tools 25); a module's
|
||||
bus credential is a minted secret written once, so a claim added to a definition reaches a running
|
||||
module only after `module issue <module> --node <machine>` and a push (postgres, both machines);
|
||||
and a registration under a seat the credential does not yet claim must be said and skipped, not
|
||||
fatal (mesh-tools 26).
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md) — extended: the same facts, issued rather than derived
|
||||
- [ADR 0152](0152-the-operators-surface-is-a-module-the-console.md), [ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md) — the surface and the seat's tools this applies to
|
||||
- [Design 25 — The bus on NATS](../03-DESIGN/01-to-be/25-the-bus-on-nats.md) §2, §3; [Design 32 — What a module declares](../03-DESIGN/01-to-be/32-what-a-module-declares.md) §1; [Design 33](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md); [Design 34](../03-DESIGN/01-to-be/34-the-console.md)
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0126-a-module-declares-its-own-seats.md
|
||||
---
|
||||
|
||||
# 161. What deserves a seat: a role of a module is a seat, a singular fact about machines is a placement with a capacity of one, and a holder's software is the machine's
|
||||
|
||||
## Context
|
||||
|
||||
Three issues asked the same question from three sides. The vault provides `secret` to the whole
|
||||
mesh and claims no seat, so nothing refuses a second vault by name
|
||||
([issue 106](../04-ISSUES/106-the-vault-claims-no-seat/00-report.md)). The hub of the private
|
||||
network is a placement, `overlay place <node> --hub`, and the issue asked whether "there is exactly
|
||||
one hub" is a seat's shape ([issue 105](../04-ISSUES/105-the-hub-of-the-private-network-is-not-a-seat/00-report.md)).
|
||||
Three modules claim the one uplink seat, one per network manager a machine might run, and nothing
|
||||
checks that the holder names the manager the machine actually runs
|
||||
([issue 138](../04-ISSUES/138-two-modules-claim-one-seat-and-are-not-interchangeable/00-report.md)).
|
||||
|
||||
Read against the code on the day of deciding:
|
||||
|
||||
- The mesh's own seats are five by [design 26](../03-DESIGN/01-to-be/26-the-seats.md)'s table and
|
||||
four in the controller's seed: `mesh-vault` is in the table and not in the seed, and the vault's
|
||||
definition claims nothing. The design also says `secret` is reserved; no parser or resolution rule
|
||||
reserves it. A second provider of `secret` would be a second candidate, settled by a pin.
|
||||
- The store already keeps one hub: a unique index since the overlay's first migration, and the
|
||||
placing command refuses a second hub naming the first. What 105 observed as silent is not.
|
||||
[ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md) decided that
|
||||
the private network becomes a mesh-scoped seat held by a server module, with client modules —
|
||||
the overlay is the host's own today, so that seat has nothing to be held by yet.
|
||||
- A machine's capabilities are its profile, detected by the host at enrolment and never since, and
|
||||
resolution refuses a module on a machine lacking one it declares, naming the capability. The uplink
|
||||
holders declare `package-manager` and `service-manager`, which every machine has.
|
||||
|
||||
[ADR 0126](0126-a-module-declares-its-own-seats.md) gave the reason the mesh's own seats exist:
|
||||
**the mesh's own code looks them up by name.** `mesh-store` is an identifier the controller
|
||||
dereferences, not a convention. That reason decides the first question; the other two are decided
|
||||
by what a seat is — a role held by a module assignment — and by what the mesh can check.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A provision the mesh itself dereferences is delivered by a mesh seat its provider claims.**
|
||||
The vault's `secret` is one: the controller seals every minted credential with it. `mesh-vault` is
|
||||
the fifth seat of the mesh's own, mesh-scoped, delivering `secret`, under
|
||||
[ADR 0079](0079-the-foundation-seats-are-named-after-their-servers.md)'s convention; the vault's
|
||||
definition claims it; a second provider of `secret` is a second claimant and refused by name. The
|
||||
word *reserved* leaves design 26: the effect it described is the seat's. Every other mesh-scoped
|
||||
provision — `smtp`, `oidc-client`, `s3-bucket`, `route`, `acme-ca` and the rest — may have several
|
||||
providers, and a consumer with several and none local is a person's choice, as the glossary says.
|
||||
The test for "deserves a seat" is the question 0126 asked: does the mesh's own code find it by name?
|
||||
|
||||
**2. A singular fact about machines is a placement with a capacity of one; a singular role of a
|
||||
module is a seat.** A seat is held by a module assignment and points at it; the hub is a machine,
|
||||
and the private network is the host's own until 0121's server and client modules exist. So the hub
|
||||
stays a placement, and what a seat would have given — refusal of a second by name, and the one
|
||||
named when asked — a placement of capacity one gives: the store keeps one (the unique index), the
|
||||
placing command refuses a second naming the one that stands, and the overlay listing names it.
|
||||
0121's seat for the private network stands, deferred with the split it needs. The rule generalises:
|
||||
a fact of the shape *exactly one machine is X* is a placement checked by the store and said by name,
|
||||
never a seat with no module to hold it.
|
||||
|
||||
**3. A holder of a seat whose role is "speak to what this machine runs" must be the dialect the
|
||||
machine runs, and the machine says which.** The host's profile gains one capability per network
|
||||
manager found active — `uplink-networkmanager`, `uplink-systemd-networkd`, `uplink-dhcpcd`, each
|
||||
`systemctl is-active` of the manager's unit — and each uplink holder declares its own. Assignment
|
||||
then refuses the wrong holder with the refusal that already exists, naming the capability; nothing
|
||||
new is judged. The profile is detected again by every apply and travels in the report, and the
|
||||
controller keeps the latest, so a machine that switches managers is, at its next push, a machine
|
||||
whose holder lacks a capability: the plan refuses and names it, which is the one thing the machine
|
||||
is the only one to know. `node-uplink` stays one seat: its three holders are three dialects of one
|
||||
role, and the capability picks the dialect. One module speaking all three is allowed by this and
|
||||
built by nobody.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The controller's seed gains `mesh-vault`; the seat table takes it additively at the next start,
|
||||
as every seed row does. The vault's definition claims it, one release after the controller.
|
||||
- The uplink definitions declare their capability one release after the host reports it, or they
|
||||
are refused on every machine in between; the order is controller (the report carries a profile),
|
||||
host, then catalogue.
|
||||
- Design 26 loses the word *reserved* for `secret` and states rules 2 and 3; the uplink row of the
|
||||
seat table names the capability its holders declare.
|
||||
- Issue 106 is resolved by rule 1, 105 by rule 2 with nothing to build, 138 by rule 3.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| `mesh-vault` is in the mesh's own set, mesh-scoped, delivering `secret`, and the vault claims it | a catalogue test on the default seats; registration refuses a second claimant by name (`CanHold`'s existing test, with the vault's seat) |
|
||||
| A second hub is refused naming the first, and the listing names the hub | the overlay command's test; the store's unique index |
|
||||
| A machine's profile names the network manager it runs, and is renewed by every report | a host detector test per manager; a controller test that a report carrying a profile replaces the stored one |
|
||||
| An uplink holder on a machine running another manager is refused, naming the capability | the existing capability refusal, exercised by a resolution test with a networkmanager machine and the systemd-networkd holder |
|
||||
| Live | `mesh-controller.seats` lists `mesh-vault` held by the vault on the control node; `plan` of a machine refuses the wrong uplink holder naming `uplink-<manager>` |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0079](0079-the-foundation-seats-are-named-after-their-servers.md), [ADR 0110](0110-a-seat-is-a-module-assignment-from-a-closed-set.md), [ADR 0117](0117-a-machines-uplink-is-a-seat.md), [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md), [ADR 0126](0126-a-module-declares-its-own-seats.md)
|
||||
- [Design 26 — The seats](../03-DESIGN/01-to-be/26-the-seats.md)
|
||||
- Issues [105](../04-ISSUES/105-the-hub-of-the-private-network-is-not-a-seat/00-report.md), [106](../04-ISSUES/106-the-vault-claims-no-seat/00-report.md), [138](../04-ISSUES/138-two-modules-claim-one-seat-and-are-not-interchangeable/00-report.md)
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0157-a-build-says-what-it-does-on-the-bus-as-it-happens.md
|
||||
---
|
||||
|
||||
# 162. A merge produces a tiered plan the mesh keeps, and a module's dependencies are one relation in the catalogue
|
||||
|
||||
> **Progressive insight — 2026-10-02.** The context below says a dependent is *built by whichever build machine is running — the only one there could be*. That was a fact of the day, not of the decision: since [ADR 0190](0190-a-seats-work-is-shared-by-its-holders-and-building-is-the-first-such-role.md) a tier's asks are taken by every machine holding the build seat. The plan and its tiers are unchanged.
|
||||
|
||||
## Context
|
||||
|
||||
A merge on the forge reaches the controller as an event, and the controller asks the build
|
||||
machine for what that merge changed. Until today that meant the modules whose recorded source is
|
||||
that repository; since this afternoon it also means everything standing on what moved
|
||||
([issue 186](../04-ISSUES/186-a-release-across-repositories-is-an-order-in-a-persons-head/00-report.md)).
|
||||
Both are done inside the handler that received the event: it asks one build, waits for it, asks the
|
||||
next, and returns when the last is done. Three things followed from that shape on 2026-10-01:
|
||||
|
||||
- The controller hears nothing else for the length of the work — twenty-five minutes for the runtime
|
||||
image and its forty-three dependents ([issue 184](../04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md)).
|
||||
- A controller replaced mid-merge loses the rest of the merge: the redelivered announcement reads as
|
||||
history, and the dependents are asked by hand.
|
||||
- Nothing is deployed between builds. A merge that changes the build machine and something the build
|
||||
machine builds asks for both in order, but the second is built by whichever build machine is running
|
||||
— the old one, unless somebody pushed in between. The order the dependents are sorted in exists for
|
||||
the artifacts; it says nothing about what must be *running*.
|
||||
|
||||
And the knowledge the order is computed from is scattered: a manifest's `build.on`, the artifacts a
|
||||
build was made against, the repositories a build read, and the fact that every source-built module is
|
||||
built by the build machine, each read by a different function in the merge handler.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A module's dependencies are one relation in the catalogue.** `depends-on` edges, each with the
|
||||
kind of dependency on it: `stands-on` (the module's artifact is built on the other's), `packages` (the
|
||||
module's build reads the other's repository), `built-by` (the module is built by the holder of the
|
||||
build-machine seat), and `declared` (a manifest's `build.on`). The relation is answered by one query
|
||||
of the catalogue — the controller's inventory today, the catalogue seat's tool when something outside
|
||||
the controller needs it — and nothing else computes an edge. The edges are derived from facts
|
||||
recorded at two moments and written by nobody: registration records the manifest (`declared`, and
|
||||
`built-by` for anything with a source), a build's take-in records what the image was built on and
|
||||
which repositories it read (`stands-on`, `packages`). A module's first build places it by its
|
||||
declared edges alone; from its second it is placed by what was true.
|
||||
|
||||
**The kinds are three dependencies, not one.** A *code* dependency — B packages A's source — means
|
||||
B is rebuilt whenever A changes, in the same tier: B's build needs nothing of A's first. A *build*
|
||||
dependency — B stands on A's artifact, or declares it — means B is rebuilt after A is *built*, the
|
||||
next tier, and nothing need be deployed in between. A *runtime* dependency — B is built by A — means
|
||||
B is rebuilt only after A is built *and running*, the next tier with a gate on the machines' reports.
|
||||
One cycle is real and resolved by the kinds themselves: the runtime image is built by the build
|
||||
machine, and the build machine stands on the runtime image; the image comes first, built by the
|
||||
build machine that is running, which is the only one there could be — a `built-by` edge never orders
|
||||
a module after a build machine that stands on it. A provision is not a dependency of this relation:
|
||||
a consumer binds to its provider through what the push renders, and a change to the provider's image
|
||||
changes nothing in the consumer's; a consumer whose build does read a provider's source declares it.
|
||||
"A was deployed, so restart B" is the push's domain — B is replaced when what it reads changed — and
|
||||
not the plan's.
|
||||
|
||||
**2. A merge produces a plan, and the plan is a record.** The controller takes the modules the merge
|
||||
changed and everything reachable from them along `depends-on` edges, and sorts that set into tiers:
|
||||
tier 0 depends on nothing else in the set, tier 1 only on tier 0, and so on. The plan — the merge it
|
||||
answers, the tiers, and each module's state — is written to the store before any build is asked. The
|
||||
handler asks tier 0 and returns. Every build's outcome, taken in by the same handler that takes every
|
||||
outcome in, advances the plan it belongs to; a controller replaced mid-plan resumes it from the store.
|
||||
|
||||
**3. A tier is done when it is built, and when what the next tier needs from it is running.** A
|
||||
module whose roll-out policy says *roll out* is sent to its machines when it moves, as today. The next
|
||||
tier is asked only once every module in this tier is built and every rolled-out module of this tier
|
||||
that a later tier is `built-by` has been applied by the machines running it — the machines' reports
|
||||
say so. A module whose policy says *record* is built and not waited for. So a merge
|
||||
touching the build machine and the controller builds the build machine, waits until it is the build
|
||||
machine that is running, and only then asks for the controller's build.
|
||||
|
||||
**4. A plan is read where the mesh is read.** `status` lists every open plan: the merge, the tier it
|
||||
is at of how many, what it is waiting for and since when; `builds` lists the asked beside the built.
|
||||
A plan that has waited past a bound is named red there, which is the first fact of
|
||||
[issue 187](../04-ISSUES/187-the-mesh-tells-nobody-when-it-stops-working/00-report.md)'s list.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The merge handler returns in milliseconds; the receive loop is never held by a build again. Issue
|
||||
184's remaining cause — a handler that waits for its own work — is removed rather than worked
|
||||
around; the bus's heartbeats stop being dropped under a merge.
|
||||
- A controller roll in the middle of a plan costs nothing: the plan is in the store and the asks are
|
||||
in the queue (mesh-controller 194).
|
||||
- A release across repositories is a plan whose edges cross repositories; the order a person kept in
|
||||
a work-order file is the order the tiers give. Issue 186's third fault is answered by the plan,
|
||||
not by a separate release record.
|
||||
- The explicit `build --on <base>` stays as the way to ask for the same plan by hand.
|
||||
- A module's `build.on` remains the one place a manifest states a dependency the store cannot see.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| Dependencies are one relation, each edge with its kind | an inventory test over a fixture catalogue: a runtime image, a module on it, a module packaging the controller's source, and the build machine; the four kinds come back from one call |
|
||||
| A merge's set is sorted into tiers along the three kinds: a code dependency in the same tier, a build dependency after its base is built, a runtime dependency after the build machine; the build machine's own base first | a unit test on the tiering over the mesh's real shape: the runtime image, the build machine on it, modules built by it, a plugin declared on one, the proxy packaging the controller, an unrelated module left out; a cycle is one last tier and said |
|
||||
| Only a runtime dependency gates on deployment, and only for a module that rolls out | the same test's gate cases |
|
||||
| The plan is written before any build is asked, and the handler returns | a controller test: a merge announcement produces a plan row with its tiers and one asked build per tier-0 module, and the handler is back before any outcome |
|
||||
| An outcome advances its plan; a complete tier asks the next; a tier with a rolled-out base waits for the machines' reports | store-backed tests over a two-tier plan: the first outcome marks built; the tier's roll-out gate holds until the report; the next tier is asked after |
|
||||
| A controller restarted mid-plan resumes it | a test that opens a plan, drops the handler, and advances from the store alone |
|
||||
| `status` lists open plans and names one that waits past the bound | the status JSON test with a fixture plan |
|
||||
| Live | a catalogue merge touching a base and a dependent: the plan's tiers in `status`, the base rolled before the dependent is asked |
|
||||
|
||||
## Built and proven live, 2026-10-01
|
||||
|
||||
> **Progressive insight — 2026-10-01.** The decision stands; these are the facts of its building.
|
||||
|
||||
Built in mesh-controller 197 (the relation, the plan record, the driver, `status`), 198 (`plans`),
|
||||
199 (a `built-by` edge orders and gates but never widens — the first live plan had taken the whole
|
||||
catalogue along for a controller change; `plans stop`), 200. The first merge handled by the finished
|
||||
machinery, at 18:56Z, was a controller change and produced the plan this record describes: tier 0
|
||||
the build machine; tier 1 the controller and the proxy that packages its source. The handler
|
||||
returned at once; the build machine was built, rolled, and the plan read *tier 0 built; waiting for
|
||||
builder on novox to be applied* until the machine reported; then tier 1 was asked, both built, and
|
||||
the plan read done — three minutes, read through the console with `plans`, the receive loop taking
|
||||
reports throughout. What the day between decision and proof taught is in issues
|
||||
[184](../04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md),
|
||||
[186](../04-ISSUES/186-a-release-across-repositories-is-an-order-in-a-persons-head/00-report.md) and
|
||||
[188](../04-ISSUES/188-a-refusal-inside-on-the-network-drops-a-machine-silently/00-report.md).
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0157](0157-a-build-says-what-it-does-on-the-bus-as-it-happens.md), [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md)
|
||||
- [Design 30 — The mesh updates itself on a push](../03-DESIGN/01-to-be/30-the-mesh-updates-itself-on-a-push.md)
|
||||
- Issues [184](../04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md), [186](../04-ISSUES/186-a-release-across-repositories-is-an-order-in-a-persons-head/00-report.md), [187](../04-ISSUES/187-the-mesh-tells-nobody-when-it-stops-working/00-report.md)
|
||||
@@ -0,0 +1,164 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0100-a-node-in-use-is-adopted-before-it-is-converged.md
|
||||
---
|
||||
|
||||
# 163. Taking a module over is a comparison: what it compares, what it refuses, and what it carries
|
||||
|
||||
## Context
|
||||
|
||||
On an adopted machine the mesh holds what it finds until the module is taken, and taking is the
|
||||
cutover ([ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md)). The whole-node flip
|
||||
is previewed and confirmed by digest; the per-module cutover, the step that actually replaces a
|
||||
running service, previews nothing. `take` names the held things the next push will replace and
|
||||
where each original is kept. It does not say how the module's version of each differs from what
|
||||
runs. Ten issues from the first migrations are the same omission seen from ten sides:
|
||||
|
||||
- a port narrowed from everywhere to the private network, unannounced ([086](../04-ISSUES/086-taking-a-module-narrows-a-port-without-saying-so/00-report.md));
|
||||
- a configuration file replaced whole, dropping the one line that was the installation's own ([098](../04-ISSUES/098-taking-a-module-replaces-a-configuration-nobody-compared/00-report.md));
|
||||
- an image pin that had aged into a downgrade, discovered by three minutes of outage ([099](../04-ISSUES/099-a-modules-image-pin-ages-into-a-downgrade/00-report.md));
|
||||
- a secret minted for a service that already had one, with no way to carry the existing value in because it was a required secret and not the module's own ([100](../04-ISSUES/100-a-minted-secret-cannot-be-the-one-the-service-already-uses/00-report.md));
|
||||
- a container moved onto the module's own network, out of reach of the neighbour that called it by name ([101](../04-ISSUES/101-taking-a-service-reached-by-container-name-cuts-its-neighbours-off/00-report.md));
|
||||
- a resource whose target changed, leaving the old container running with no record naming it ([097](../04-ISSUES/097-a-resource-that-changes-target-leaves-the-old-one-behind/00-report.md));
|
||||
- a volume path that changed without the running container noticing, because the host does not compare that field ([126](../04-ISSUES/126-a-volume-path-is-not-in-the-spec-comparison/00-report.md));
|
||||
- a build that deployed at once because the module's policy said so, racing a data move ([126](../04-ISSUES/126-a-volume-path-is-not-in-the-spec-comparison/00-report.md));
|
||||
- a setting accepted where it was set and refusing the whole machine where it was read ([096](../04-ISSUES/096-a-setting-that-cannot-work-is-stored-and-stops-the-node/00-report.md));
|
||||
- a module that could not take over what genesis raised, because the two differed in name, network, data and image ([090](../04-ISSUES/090-the-forge-module-does-not-take-over-the-forge-genesis-raised/00-report.md));
|
||||
- a successor that could not stand beside its predecessor at all, answered by [ADR 0104](0104-a-provision-may-be-answered-by-an-adapter-to-the-predecessor.md)'s adapter ([093](../04-ISSUES/093-the-successor-proxy-cannot-serve-what-the-predecessor-still-serves/00-report.md)).
|
||||
|
||||
What the host records of a found thing is enough to compare from: a file's original, kept, with
|
||||
its digest, mode and owner; a container's id and whether it ran; whether anything changed it
|
||||
since. What it does not yet record is what a comparison needs most: the found container's image
|
||||
and when that image was made, the networks it is on and who else is on them, what it mounts, what
|
||||
it publishes. And the controller's rule that a machine is told everything or nothing turns one
|
||||
impossible statement into a machine nobody can talk to.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A take is previewed, and the preview is a comparison.** For every held thing the module would
|
||||
replace, `take` puts what runs beside what the module declares and says the difference:
|
||||
|
||||
- a **container**: its image against the module's, with each image's creation date so older and
|
||||
newer have a meaning; its name; its networks, and the other containers on each found network
|
||||
that is not the module's; its published ports and the reach of each, found firewall and guard
|
||||
included; its mounts against the module's volumes and paths;
|
||||
- a **file**: the kept original against the declared content, as a difference, not two digests;
|
||||
- a **secret** the module takes that the mesh minted and nobody accepted, when the service's data
|
||||
was found — a service that already runs already has a value;
|
||||
- the module's **settings** on that machine, composed against its definition.
|
||||
|
||||
`take` without `--yes` prints the comparison and stops; `take --yes <digest>` cuts over exactly
|
||||
what was previewed, the way the flip is confirmed, and a preview whose account of the machine is
|
||||
older than the flip allows is refused the same way. The host supplies the facts in its report of
|
||||
what it holds: the found container's image and its creation date, its networks and their members,
|
||||
its mounts and published ports.
|
||||
|
||||
**2. Three differences refuse by default, each overridden by naming it.** An image **older** than
|
||||
the one running, by creation date — `--downgrade`, said once and recorded. A declared file that
|
||||
**differs** from the kept original — `--replace <path>`, or the module declares the file partially
|
||||
and writes into it ([ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md)), which is
|
||||
the right answer wherever the file is the service's own and the format allows it. A **minted,
|
||||
unaccepted secret** for a service whose data was found — accept the value first, or `--mint
|
||||
<name>` to say the service shall take a new one. Two differences are said and not refused: a port
|
||||
whose reach **narrows**, and a found network whose other members may reach the container **by
|
||||
name**, each member named; both are the operator's to weigh, and the words are there to weigh them.
|
||||
|
||||
**3. A secret the mesh would mint may be accepted instead, own or required.** `secret accept`
|
||||
reaches a module's required secrets, not only its own: the value is a fact about the machine, and
|
||||
the mesh's job at a take is to learn it. The accepted value is sealed to the module as a minted one
|
||||
would be, and the provider that would have minted it is told it has one. Whether one accepted
|
||||
value should reach every consumer of a provider at once is [issue 165](../04-ISSUES/165-one-accepted-value-must-be-accepted-once-per-consumer/00-report.md)'s
|
||||
question and the next group's.
|
||||
|
||||
**4. A taken container may keep a found network, for a while, by a setting.** A per-machine
|
||||
setting names a found network the module's container also joins, so a neighbour that resolves it
|
||||
by name keeps resolving it. It is migration scaffolding in the sense of
|
||||
[ADR 0104](0104-a-provision-may-be-answered-by-an-adapter-to-the-predecessor.md): assigned only on an
|
||||
adopted machine, reported while it stands, removed when the neighbours are taken, and the preview
|
||||
names it. Taking a group of modules at once is not decided here; the setting makes the order free.
|
||||
|
||||
**5. The host compares every field it writes, and removes what it can no longer name.** A
|
||||
container is current when every field the host would write agrees with the one running — volumes
|
||||
and paths included; a field the host cannot compare recreates rather than passes. The host's
|
||||
record keeps a resource's former targets: a container or file the host **wrote** under a name or
|
||||
path the declaration no longer names is removed on the next apply and said; what was **found** is
|
||||
never removed, as ADR 0100 says. And the host answers the question nothing answered on
|
||||
2026-09-23: its report lists what runs on the machine that the mesh neither wrote nor holds —
|
||||
containers and listeners — as *strays*, so a thing left behind is seen the day it is left.
|
||||
|
||||
**6. A setting is judged where it is stored, and an impossible one costs a module, not a machine.**
|
||||
Storing a setting composes it against the module's current definition and refuses with the node,
|
||||
module, layer and key when it cannot work. A definition that later moves under a stored setting
|
||||
makes composition leave *that module* out of the machine's declaration — its held things kept, its
|
||||
containers untouched — and say the statement by name; the machine is still told everything else.
|
||||
A machine is told everything or nothing about what it *is* told; what it is not told is said.
|
||||
|
||||
**7. What genesis raises, it raises as the module that succeeds it declares** — name, network,
|
||||
data directory and image — so the module adopts it by the found rule that already exists, and a
|
||||
module meant to succeed a bootstrap service that it cannot adopt is a fault of genesis, found by a
|
||||
test that raises and then assigns. **`build` says when a policy will act on its result**, so a
|
||||
person choreographing a data move knows which module will not wait; under
|
||||
[ADR 0162](0162-a-merge-produces-a-tiered-plan-the-mesh-keeps.md) the roll-out is the plan's, and
|
||||
the plan says it too.
|
||||
|
||||
## Consequences
|
||||
|
||||
- `take` becomes the per-module twin of the flip: preview, digest, confirm. The flip's own preview
|
||||
gains the same comparisons for every module it takes.
|
||||
- The host's report of what it holds grows by the found container's image and creation date,
|
||||
networks and members, mounts and published ports; its store keeps former targets and strays.
|
||||
- Issues 086, 098, 099, 100, 101 close on rule 1 and 2; 097 and 126 on rule 5; 096 on rule 6;
|
||||
090 on rule 7; 093 is closed by ADR 0104's adapter, which runs.
|
||||
- Nothing here changes what an adopted machine keeps or when: found stays held, held is never
|
||||
removed, the original is kept before anything is written.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| The host reports a found container's image and creation date, networks and their members, mounts and published ports | host unit tests over a fake runtime; the adoption bed's report |
|
||||
| `take` without `--yes` previews every held thing's difference and changes nothing; `--yes` with the digest cuts over; a stale account is refused | controller tests over a fixture report: a differing file, an older image, a narrowed port, a shared network, a minted secret |
|
||||
| An older image, a differing file and a minted secret for found data refuse without their override | the same tests |
|
||||
| A found network kept by a setting is joined, reported and named in the preview | a host test and a controller resolution test |
|
||||
| `secret accept` takes a required secret | an inventory test; the provider is told |
|
||||
| Every container field is compared; a former target the host wrote is removed and said; what was found is not | host tests: a volume path change recreates; a renamed container's predecessor is removed; a found one under the old name is kept |
|
||||
| Strays are reported | a host test over a fake runtime with a container nobody declared |
|
||||
| A setting that cannot compose is refused where stored, naming node, module, layer, key; a definition moving under one leaves that module out and says so | controller tests |
|
||||
| Genesis raises the forge as its module declares it | a genesis test that raises, assigns, and finds the module holding rather than raising a second |
|
||||
| Live | the next cutover on an adopted machine: `take` shows the comparison, refuses the downgrade if there is one, and the service keeps its configuration and its secret |
|
||||
|
||||
## Built, 2026-10-02
|
||||
|
||||
> **Progressive insight — 2026-10-02.** The decision stands; these are the facts of its building.
|
||||
|
||||
Built across mesh-host 63 and 64 and mesh-controller 201, 202 and the pull request that followed
|
||||
them. Rule 1: `take` previews every held thing's comparison and ends with a digest; `take --yes
|
||||
<digest>` acts on exactly that preview, and a changed preview or an account older than the flip
|
||||
allows is refused, as the flip's are. A published port's reach is said as the machine reported it,
|
||||
behind the found firewall whose rules are not read. Rule 2: an older image, a differing file and a
|
||||
minted, unaccepted secret for found data refuse, overridden by `--downgrade`, `--replace <path>` and
|
||||
`--mint <name>`; the secrets a module holds on a machine are read with where each came from. Rule 3:
|
||||
`secret accept --provider` reaches a required secret. Rule 4: the per-machine setting is `networks`,
|
||||
a container id to the found networks it keeps; judged for an adopted machine only, joined by the host
|
||||
after the container runs, part of the container's spec, named in the preview. Rule 5: the host's
|
||||
facts, former targets and strays. Rule 6: one judgement, run where a setting is stored and where a
|
||||
machine is composed; a module whose stored setting its definition can no longer compose is left out
|
||||
of the declaration, the envelope says so, the host keeps that module's things, and `plan` and `push`
|
||||
say it by name. A key that reaches nothing is refused where stored and said by `plan`, and never
|
||||
costs a module. Rule 7: genesis raises the forge under the module's container name, with its image
|
||||
digest and its data directory; the network is the one difference left, said by the take, because the
|
||||
bootstrap forge reaches the store on the machine's loopback.
|
||||
|
||||
**Not yet proven live.** Every machine of this mesh is converged, so the table's last row — a take
|
||||
on an adopted machine — waits for the next adoption. What is live is what the rows above it check.
|
||||
Issues 086, 098, 099, 100 and 101 stay located until that row is read.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md), [ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md), [ADR 0103](0103-what-an-adopted-node-holds-and-what-its-guard-refuses.md), [ADR 0104](0104-a-provision-may-be-answered-by-an-adapter-to-the-predecessor.md), [ADR 0162](0162-a-merge-produces-a-tiered-plan-the-mesh-keeps.md)
|
||||
- [Design 05 — The node host](../03-DESIGN/01-to-be/05-the-node-host.md), [Design 09 — The node lifecycle](../03-DESIGN/01-to-be/09-the-node-lifecycle.md)
|
||||
- Issues 086, 090, 093, 096, 097, 098, 099, 100, 101, 126
|
||||
+146
@@ -0,0 +1,146 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: proposed
|
||||
date: 2026-10-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0046-a-module-configuration-is-its-assignments-not-its-manifest.md
|
||||
---
|
||||
|
||||
# 164. A setting is declared with its default, its meaning and what changing it costs
|
||||
|
||||
## Context
|
||||
|
||||
The operator asked for one thing for every module, with the container runtime as the first case: **one
|
||||
consistent default configuration for every machine, overridable per assignment, and easy to change
|
||||
later.** The four machines' runtime configurations were each written by hand and differ — one keeps
|
||||
running containers through a daemon restart and one does not, their log rotation differs, and each
|
||||
names its resolver and its trusted registries in its own words.
|
||||
|
||||
Most of this was already decided.
|
||||
[ADR 0046](0046-a-module-configuration-is-its-assignments-not-its-manifest.md) said the definition is
|
||||
identity and **defaults**, the assignment's settings are the configuration, *unset is the default*, and
|
||||
*an unknown setting is refused*. [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md) made
|
||||
a setting an operator requirement whose contract is "a type and, optionally, a default", answered by
|
||||
"the assignment's, or the requirement's default, or unresolved". An assignment is a module on a node,
|
||||
so the node layer of a module's settings already *is* the per-assignment override, and the mesh-wide
|
||||
layer is the one consistent default a person changes once.
|
||||
|
||||
What was built is narrower than what was decided, measured in the controller on the day of deciding:
|
||||
|
||||
- **Nothing declares which keys are settable.** A mergeable file's content is its defaults, and every
|
||||
key of it — and every key not in it — is accepted. Nothing tells a person, or the console, what can be
|
||||
set, of what type, or what it means.
|
||||
- **The refusal of an unknown setting is not there for most modules.** The stray-setting report returns
|
||||
nothing at all for a module with any mergeable file, because such a file "takes any key"
|
||||
([issue 173](../04-ISSUES/173-a-modules-settings-reach-every-fact-it-contributes/00-report.md) left
|
||||
files that way on purpose). It reports rather than refuses where it does run.
|
||||
- **A value in a file that is not JSON can have no default.** `${setting:<key>}`
|
||||
([ADR 0155](0155-a-definition-names-no-installation-and-how-that-is-checked.md)) is refused when no
|
||||
layer sets it — right for a mail domain, where a default is the very literal 0155 removes, and wrong
|
||||
for a tunable like the resolver's upstreams, which the resolver module therefore carries as literals
|
||||
in its file.
|
||||
- **A setting reaches every mergeable file its module owns.** The layers are one flat map per module,
|
||||
laid over each such file. Adding a setting to the resolver module for its own configuration put the
|
||||
key into the container runtime's file as well — the resolver writes into that file too — and the
|
||||
runtime refuses keys it does not know. The plan showed it before any push; the runtime's file was
|
||||
then made to take no settings at all ([issue 198](../04-ISSUES/198-the-lans-dns-server-ran-outside-the-mesh-and-its-filter-closed-it/00-report.md)). Issue 173 stopped settings leaking into
|
||||
contributions and served facts; between one module's own files the leak remains.
|
||||
- **What a change costs is said per file, not per key.** A service names the files it is reloaded or
|
||||
restarted on. The runtime re-reads its trusted registries on a reload and its `dns` key only when it
|
||||
starts; the resolver module declared a reload, so on two machines the key was written, reloaded,
|
||||
and never read, and every container got a public resolver for weeks while everything read as
|
||||
current ([issue 110](../04-ISSUES/110-a-container-on-the-runtimes-own-network-cannot-reach-the-resolver/01-resolution.md)).
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Leave settings implicit; document each module's keys in its README.** Rejected: a key the mesh
|
||||
does not know cannot be refused, typed, listed by the console or costed, and a README is a rule
|
||||
enforced by nothing.
|
||||
2. **A second mechanism for tunables beside settings** — defaults in a new block, settings untouched.
|
||||
Rejected: two ways to state one person's value, and design 27 already retires six mechanisms
|
||||
that grew that way.
|
||||
3. **Settings declared in the definition, as 0112's operator requirement: a key, a type, a meaning,
|
||||
optionally a default, and what a change costs.** Adopted.
|
||||
|
||||
## Decision
|
||||
|
||||
**A module declares every setting it takes.** Each declared setting has a name, a type, one sentence
|
||||
of meaning, optionally a default, and what a change to it costs. The spelling is design 27's to settle
|
||||
with the rest of the requirement form; this record decides the content.
|
||||
|
||||
**A setting with a default is a tunable; a setting without one is the operator's.** A tunable resolves
|
||||
to its default when no layer sets it — wherever it is read, a mergeable file or `${setting:<key>}` in a
|
||||
file of any format. A setting with no default is refused by name when nothing sets it, as 0155 decided;
|
||||
0155's refusal is narrowed to exactly that case, not changed for it. Whether a value has a default is a
|
||||
fact about the software (a log size does, a mail domain does not), and the definition states it once.
|
||||
|
||||
**The layers stay as they are, and every value says where it came from.** The definition's default,
|
||||
then the mesh-wide layer, then the node's — later wins, objects merge, lists replace. One consistent
|
||||
configuration for every machine is the default plus the mesh-wide layer; one machine that differs says
|
||||
so in its own layer and nothing else. Asked for a module's configuration on a machine, the mesh lists
|
||||
every declared setting with its effective value and its source: *default*, *mesh*, or *node*.
|
||||
|
||||
**Changing later is changing one of three places, and the plan shows its reach before anything moves.**
|
||||
A new default ships with the module's next version and reaches every assignment that does not override
|
||||
it; a mesh-wide setting reaches every assignment of the module; a node's reaches one. The plan of a
|
||||
change names each assignment whose effective value moves.
|
||||
|
||||
**A declared setting says where it lands.** Each names the file or files of its module that read it,
|
||||
and reaches no other: a module that owns two mergeable files no longer has one flat map laid over both.
|
||||
A file that names no setting takes none.
|
||||
|
||||
**A declared setting is the only kind accepted.** Setting a key the module does not declare is refused
|
||||
when it is set, naming the declared keys, rather than reported when the machine is planned. The mesh's
|
||||
own words — where a port, a directory or an operator's data is placed, how far an endpoint reaches —
|
||||
are the mesh's to validate as they are today, and no module declares them. A module
|
||||
that declares no settings keeps today's behaviour until it does; a catalogue test lists those modules,
|
||||
and the list shrinks to empty before the implicit form is removed — design 27's rule for every retired
|
||||
mechanism.
|
||||
|
||||
**A setting says what it costs: nothing, a reload, or a restart.** When a file changes, the host
|
||||
applies the strongest cost among the settings whose values moved in it, so a key the software reads
|
||||
only at start can no longer be written and never read. A setting that reaches a container's environment
|
||||
costs that container being recreated, which the host already does when a container's specification
|
||||
changes; it needs no declaration. A service's `reload-on` and `restart-on` keep
|
||||
naming the files that are not settings — a generated roster, a credential.
|
||||
|
||||
**The container runtime is the first module to declare its settings** and the model for the rest:
|
||||
its log rotation, keeping containers through a daemon restart, and its resolver are tunables, and
|
||||
its trusted registries are what the mesh tells it.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The console can show a module's settings as a form: what can be set, of what type, its default,
|
||||
and where the current value came from. That is the surface the operator wants for changing a
|
||||
default later.
|
||||
- `settings set` can refuse an unknown key, so ADR 0046's rule is enforced where it was only stated.
|
||||
- The resolver's upstreams, the runtime's log rotation, and other literals a definition carries
|
||||
because it could not give them a default become declared tunables.
|
||||
- **What got harder:** every module that takes settings must list them, and a mergeable file no
|
||||
longer silently accepts a key its author did not foresee. A person who needs one adds it to the
|
||||
definition, which is a new module version, not a setting.
|
||||
- Issue 173's open question — a consumer checks nothing against a contract — is unchanged; this record
|
||||
is the operator half of design 27's contract, not the provider half.
|
||||
- Not decided here: the spelling (design 27); whether a node's layer may be narrowed to a single key
|
||||
rather than replaced whole, as `settings set` does today.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| Every setting a module takes is declared | A parser test refusing a setting declaration without a type or meaning; a catalogue test listing modules with mergeable files or `${setting:}` and no declarations, which must be empty before the implicit form is removed |
|
||||
| A tunable resolves to its default; an operator value without one is refused | Resolution tests: an unset tunable in a JSON file and in a text file both take the default; an unset setting with no default is refused naming it (0155's existing test) |
|
||||
| A setting reaches only the files it names | A resolution test: a module with two mergeable files and a setting declared for one; the other file's content is unchanged by it (the case of issue 198) |
|
||||
| An undeclared key is refused when set | A controller test: `settings set` with an undeclared key fails naming the declared keys, and nothing is stored |
|
||||
| Every effective value names its source | A test listing a module's configuration on a node with one key from each of default, mesh and node |
|
||||
| A change's reach is shown before it moves | A plan test: changing a mesh-wide setting names every assignment whose effective value moves and no other |
|
||||
| The strongest cost applies | A host test: a file where a reload-cost key and a restart-cost key both moved restarts; a file where only reload-cost keys moved reloads |
|
||||
| Live | The container runtime's module lists its settings with their sources on every machine, and a mesh-wide change to its log rotation reaches all four at the next push |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0046](0046-a-module-configuration-is-its-assignments-not-its-manifest.md), [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md), [ADR 0155](0155-a-definition-names-no-installation-and-how-that-is-checked.md), [ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md)
|
||||
- [Design 27 — a module requires, the mesh resolves](../03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md)
|
||||
- Issues [110](../04-ISSUES/110-a-container-on-the-runtimes-own-network-cannot-reach-the-resolver/00-report.md), [173](../04-ISSUES/173-a-modules-settings-reach-every-fact-it-contributes/00-report.md)
|
||||
- mesh-controller `internal/catalogue/settings.go` (`settle`, `UnusedSettings`), `internal/catalogue/setting_into.go`
|
||||
+105
@@ -0,0 +1,105 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: proposed
|
||||
date: 2026-10-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0161-what-deserves-a-seat.md
|
||||
---
|
||||
|
||||
# 165. `container-runtime` is what a machine can run; that a runtime is running is its holder's health
|
||||
|
||||
## Context
|
||||
|
||||
A capability is a requirement a module places on a machine, detected by the host and renewed with
|
||||
every report ([ADR 0161](0161-what-deserves-a-seat.md)). The host's `container-runtime` asks the
|
||||
daemon for its version: *a running daemon, not an installed client*. It was made that way by
|
||||
[issue 007](../04-ISSUES/007-an-installed-package-is-not-a-capability/00-report.md), where an
|
||||
installed package was believed to be a working service, and
|
||||
[design 05](../03-DESIGN/01-to-be/05-the-node-host.md)'s table says the same: *a runtime is
|
||||
running*. The installer's preflight borrows the same detector to wait for the runtime the
|
||||
foundation bundle installs, so there is one answer to "is there a runtime here".
|
||||
|
||||
The mesh is now to have a module for the runtime itself — its packages, its configuration, its
|
||||
service — on every machine ([ADR 0166](0166-the-container-runtime-is-a-node-seat-and-the-host-creates-containers-through-its-holder.md)).
|
||||
That module cannot declare `container-runtime` as defined: it would require the very thing it
|
||||
installs, the cycle [research 011](../01-RESEARCH/011-the-module-graph/cases.md)'s case 12 names
|
||||
("something the mesh installs that then becomes a node capability"). The operator defined the word
|
||||
for it: **`container-runtime` means the machine is able, at the kernel level, to install a runtime and
|
||||
execute containers** — not that one is installed, and not that one is running.
|
||||
|
||||
The host already draws this line once. `seat` is hardware, a display server *could* run here;
|
||||
`graphical-session` is state, one *is* running; the detector's own comment says "assignment needs the
|
||||
first". A machine without a display has no seat however much software is installed, and a machine
|
||||
with one has a seat before anything is.
|
||||
|
||||
Fifty-four catalogue modules declare `container-runtime` today, counted on the catalogue's main
|
||||
branch on the day of deciding: every module that delivers a container. Each relies on the current
|
||||
meaning to keep it off a machine with no running runtime.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep the meaning; let the runtime's module declare nothing.** Rejected: a module that installs
|
||||
the runtime has requirements on the machine — the kernel features without which installing it is
|
||||
pointless — and would state none of them. The cycle stays, only hidden.
|
||||
2. **Two capabilities, "can run" and "is running".** Rejected: the second is made true by assigning a
|
||||
module, so it is the module's state, not a fact of the machine; a capability the mesh itself
|
||||
flips by its own assignment is case 12's cycle with an extra name.
|
||||
3. **The capability is the kernel's; whether a runtime runs is the runtime module's health, and a
|
||||
module that delivers a container needs the runtime's seat held.** Adopted.
|
||||
|
||||
## Decision
|
||||
|
||||
**`container-runtime` is detected from what the kernel offers**, as `seat` is: the namespaces a
|
||||
container needs, a control-group hierarchy the runtime can manage, and an overlay filesystem the
|
||||
running kernel has or can load. Present when all three are; absent naming the missing one. Nothing is
|
||||
run and no runtime is asked. The verdict's detail names what was found, not a runtime's version.
|
||||
|
||||
**"A runtime is running and answers" is one probe, owned by the host and used twice:** by the
|
||||
installer's preflight, which waits for the runtime the foundation installs, and as the runtime
|
||||
module's health. It asks the daemon, as issue 007 requires. The preflight stops borrowing the
|
||||
capability's detector, and there is still one answer to "is a runtime running here".
|
||||
|
||||
**The runtime's module declares `container-runtime`**, with `package-manager`, `service-manager` and
|
||||
`privileged`, like any module that manages machine software.
|
||||
|
||||
**A module that delivers a container needs the runtime seat held on its machine**, and is refused
|
||||
otherwise, naming the seat and the modules that could hold it — the refusal design 27 already lists
|
||||
for an unheld seat. That requirement is derived from the container resource and needs no manifest
|
||||
field ([ADR 0166](0166-the-container-runtime-is-a-node-seat-and-the-host-creates-containers-through-its-holder.md)).
|
||||
The fifty-four existing declarations of the capability stay valid and become redundant; a catalogue
|
||||
test lists them, and they retire when the list is empty.
|
||||
|
||||
**The order is fixed, not preferred.** The detector changes only once the seat requirement is
|
||||
enforced. In between, a machine with the kernel and no running runtime would read as able to run
|
||||
every containerised module, which is issue 007 again.
|
||||
|
||||
## Consequences
|
||||
|
||||
- Design 05's capability table changes its `container-runtime` row from *a runtime is running* to
|
||||
*the kernel can run containers*, and names the runtime module's health as where "running" is now
|
||||
asked.
|
||||
- The node listing stops showing the runtime's version beside the capability. The version moves to
|
||||
the runtime module's health and its seat's verbs.
|
||||
- A fresh machine with no runtime reads as able to run one, so it can be assigned the runtime's
|
||||
module, which is what makes the mesh able to install the runtime instead of the bootstrap alone.
|
||||
- **What got harder:** "is this machine running containers" is no longer one glance at the profile;
|
||||
it is the runtime seat's holder and its health. The node's listing should show both side by side.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| The capability is the kernel's | Host detector tests over a fixture `/proc` and `/sys`: all three present → present; each one missing → absent naming it; no runtime binary on the fixture machine changes nothing |
|
||||
| One probe asks whether a runtime runs | A host test that the preflight and the runtime module's health call the same probe, and that the probe fails against a stopped daemon with an installed client (issue 007's shape) |
|
||||
| A containerised module needs the runtime seat held | A resolution test: a module with a container resource on a machine whose runtime seat is unheld is refused, naming the seat and its candidate holders |
|
||||
| The order holds | The host release that changes the detector is gated on the controller release that enforces the seat requirement — stated in both changes' descriptions and checked at review |
|
||||
| Live | Every machine's profile shows `container-runtime` present with the kernel's features as its detail; a machine with no runtime installed reads present too |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0161](0161-what-deserves-a-seat.md) — the profile renewed by every report; a capability that names a dialect
|
||||
- [ADR 0166](0166-the-container-runtime-is-a-node-seat-and-the-host-creates-containers-through-its-holder.md) — the seat and its holder
|
||||
- [Issue 007](../04-ISSUES/007-an-installed-package-is-not-a-capability/00-report.md), [research 011](../01-RESEARCH/011-the-module-graph/cases.md) cases 12–13
|
||||
- [Design 05 — the node host](../03-DESIGN/01-to-be/05-the-node-host.md)
|
||||
- mesh-host `internal/profile/detectors.go` (the runtime detector), `internal/profile/seat.go` (the hardware/state split), `internal/bootstrap/preflight.go` (the preflight that borrows it)
|
||||
+161
@@ -0,0 +1,161 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: proposed
|
||||
date: 2026-10-01
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0161-what-deserves-a-seat.md
|
||||
---
|
||||
|
||||
# 166. The container runtime is a node seat, and the host creates containers through its holder
|
||||
|
||||
## Context
|
||||
|
||||
Every container the mesh runs on a machine is created by the host, which looks for a runtime
|
||||
(`docker info`, then `podman info`) and drives that runtime's command line itself: run, inspect,
|
||||
remove, exec. Research 012 called this "detected rather than declared": the host takes over whatever
|
||||
runtime it finds. Nothing in the mesh owns the runtime. Its package came from the foundation bundle
|
||||
or was already on the machine. Its configuration file was written by hand, differs on each of the
|
||||
four machines, and is also written into by two modules that are not the runtime's
|
||||
([issue 190](../04-ISSUES/190-the-runtimes-configuration-is-written-by-modules-that-are-not-the-runtime/00-report.md)).
|
||||
Its service is declared by those same two.
|
||||
|
||||
The operator set the direction:
|
||||
|
||||
- a module for the runtime, on every machine, owning "what is needed to run containers here": its
|
||||
packages, its configuration and its service;
|
||||
- that module holds a node seat for the runtime, so a second runtime (podman) can later compete
|
||||
for the seat;
|
||||
- the host stops speaking to the runtime directly and uses the seat's holder. The host stays the one
|
||||
that decides, and the holder becomes the one that executes;
|
||||
- every container on the machine is in scope, not only the mesh's. A development environment started
|
||||
by hand, or a test database a tool runs, is legitimate. The host already calls these *strays*: 3,
|
||||
8 and 25 on three of the machines on the day of deciding;
|
||||
- the runtime's events and verbs are subjects on the bus, and the mesh's own interface is built on
|
||||
them. The third-party interface run until now was removed by hand.
|
||||
|
||||
[ADR 0161](0161-what-deserves-a-seat.md)'s test for a seat is whether the mesh's own code finds it by
|
||||
name. Here it does: the host would look up the holder on its own machine. A singular role of a module
|
||||
held once per machine is a `node-*` seat ([ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md)),
|
||||
in the controller's seed.
|
||||
|
||||
The constraint that decides most of this record is a cycle. The bus runs in containers. On the
|
||||
broker's machine, the broker's own container is created by the host. A holder's code served from a
|
||||
container cannot create the container that runs it. On a first machine, before the controller exists,
|
||||
nothing holds anything.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **The host calls the holder's verbs over the bus.** Rejected: with the broker down, no machine can
|
||||
create any container, including the broker's. The mesh would be unable to restart its own
|
||||
transport.
|
||||
2. **The holder picks a dialect that the host speaks itself, as with the uplink.** Rejected: the
|
||||
host would still drive the runtime, and the module would drive it too for every other caller.
|
||||
That is two programs speaking to one daemon, and they come to disagree about the same machine
|
||||
(the installer's preflight already exists to avoid this).
|
||||
3. **The holder's code runs as a supervised process on the machine and serves the seat's verbs
|
||||
twice: locally to the host, on the bus to everyone else.** Adopted.
|
||||
|
||||
## Decision
|
||||
|
||||
**`node-container-runtime` is a seat of the mesh's own, node-scoped,** in the controller's seed under
|
||||
this record. It delivers no provision; what it carries is its role's protocol: verbs its holder must
|
||||
serve ([ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md)) and events its holder emits
|
||||
([ADR 0129](0129-a-seat-carries-the-protocol-of-its-role.md)). The runtime's module, `docker`, claims
|
||||
it and is assigned to every machine. A podman module may claim it later; one machine runs one.
|
||||
|
||||
**The seat's verbs cover every container on the machine:** list, inspect, logs, stats, start, stop,
|
||||
restart, create and remove. A mesh-held container is marked by the host's label and says which
|
||||
assignment holds it. **A container the runtime runs can be root on the machine** — privileged, a host
|
||||
path mounted, the host's network or process namespace, the runtime's own socket — so a caller other
|
||||
than the host may not create one that is any of these; only a declaration the mesh composed may ask
|
||||
for them. And the verbs that change anything are granted by name, never by a wildcard: a grant of
|
||||
every tool (the console's today) reaches the reading verbs only. Issue 193 is what a verb that trusts
|
||||
its caller costs. **Creating or removing a mesh-held container is the host's alone.** Any other
|
||||
caller is refused naming the assignment, because the host would undo it at its next apply. Starting,
|
||||
stopping or restarting one is allowed, and the answer says the host will restore what its
|
||||
declaration says. A container the mesh does not hold is the caller's to do anything with.
|
||||
|
||||
**The seat's events are the runtime's own** — a container created, started, stopped, died, removed,
|
||||
its health changed. They are emitted on the seat's subjects, so every holder emits the same events and
|
||||
no reader depends on which runtime holds the seat. As
|
||||
[ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md)
|
||||
decides, the subjects are issued by the controller, not composed by the module.
|
||||
|
||||
**The holder's code is a supervised process, not a container** ([ADR 0150](0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md)).
|
||||
A runtime cannot be run by the thing it runs. The process serves the seat's verbs on the bus to the
|
||||
console, to tools and to the mesh's interface. The same verbs are served on a local socket on the
|
||||
machine, which only the host may use. **The host creates, inspects and removes its containers
|
||||
through that socket and nothing else.** If the holder does not answer, the host creates nothing. It
|
||||
says so in its report, naming the seat. It never falls back to the command line.
|
||||
|
||||
**A container needs the seat held on its machine.** An assignment that delivers a container on a
|
||||
machine whose runtime seat is unheld is refused, naming the seat and its candidates
|
||||
([ADR 0165](0165-container-runtime-is-what-a-machine-can-run-and-a-running-runtime-is-its-holders-health.md)).
|
||||
Mounting the runtime's socket into a container is granted by the seat, not by the capability. The
|
||||
socket's path is the holder's to state, because podman's is not docker's.
|
||||
|
||||
**The runtime module owns the runtime's configuration.** Its settings are declared with defaults
|
||||
([ADR 0164](0164-a-setting-is-declared-with-its-default-its-meaning-and-what-changing-it-costs.md)):
|
||||
the resolver containers use, the registries it trusts, log rotation, and keeping containers through a
|
||||
daemon restart. The module is given the resolver's address and the mesh's registry as values; no other
|
||||
module writes the runtime's file or declares its service.
|
||||
|
||||
**The first machine is bootstrapped with the holder, and adopted afterwards.** The foundation bundle
|
||||
already installs the runtime's package and service. It also carries the holder's process, delivered as
|
||||
a binary the way the host is ([ADR 0142](0142-the-mesh-delivers-its-own-components-as-binaries.md)).
|
||||
When the runtime module is assigned, it adopts what the bundle made, as the store and broker modules
|
||||
adopt theirs ([ADR 0078](0078-the-store-and-broker-are-modules.md)).
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The migration on the running mesh has a fixed order:**
|
||||
1. Each machine's hand-written configuration is read, because the module's defaults replace what
|
||||
differs.
|
||||
2. In one push per machine: the resolver module and the private network stop writing the
|
||||
runtime's file ([issue 190](../04-ISSUES/190-the-runtimes-configuration-is-written-by-modules-that-are-not-the-runtime/00-report.md)),
|
||||
and the runtime module is assigned and adopts the runtime, its file and its service. Split in
|
||||
two, either the controller refuses two modules declaring one path, or a machine is left with
|
||||
nothing setting `dns` and `live-restore`.
|
||||
3. The controller seeds the seat and enforces the container requirement.
|
||||
4. The host releases the version that uses the holder.
|
||||
5. The host's command-line path is removed in the release after every machine's holder answers.
|
||||
Until then, the host reports per machine which path it used.
|
||||
- **Every container the host makes depends on the holder's process.** A crash-looping holder stops
|
||||
new containers on its machine. Running containers are unaffected. The host's report names the cause.
|
||||
- The process form of a module's own code must serve tools on the live mesh before this ships. Only the
|
||||
showcase declares it, and [issue 117](../04-ISSUES/117-a-modules-own-code-is-a-container-and-a-process/01-diagnosis.md)
|
||||
found the showcase's tools declared in a form nothing runs. The runtime module is the first whose
|
||||
tools cannot fall back to a container.
|
||||
- A user interface subscribing to events directly does not exist. Today a reader of events is a module
|
||||
that consumes them. The mesh's container view is a module, or waits for that path.
|
||||
- [ADR 0005](0005-the-node-host.md) ("a container runtime is detected, not chosen") and
|
||||
[ADR 0006](0006-the-substrate-and-the-control-plane.md)'s matching line describe the mechanism this replaces: on
|
||||
acceptance, each gets a dated note saying the runtime is now a seat's holder, as the decision
|
||||
records' rule for a moved mechanism requires. Design 05 and design 26 are amended after acceptance.
|
||||
- The operator's decision to remove the third-party interface by hand needs no mechanism. No
|
||||
module-retires-module rule is introduced.
|
||||
- **What got harder:** the host gains a dependency it did not have, and a first machine's bundle gains
|
||||
a component. The direct path was simpler and is what makes a runtime a black box to the rest of the
|
||||
mesh.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| The seat is the mesh's own, node-scoped, with its verbs and events | A catalogue test on the default seats; registration refuses a claimant that does not serve every verb (design 33's existing check) |
|
||||
| Creating or removing a mesh-held container is the host's alone | A test of the runtime module's verbs: create or remove of a container carrying the host's label, from any caller but the host's socket, is refused naming the assignment; the same verbs on an unlabelled container succeed |
|
||||
| No caller but the host creates a container that is root on the machine | A test of `create` from the bus: privileged, a host path, the host's namespaces and the runtime's socket are each refused; the same request on the host's socket is accepted. A broker test: a grant of every tool does not reach a changing verb |
|
||||
| The host uses the holder and never the command line | A host test with a fake holder on the local socket: every container operation goes to it, and with the holder absent the apply creates nothing and reports the seat; after step 5, the host carries no command-line runtime code (checked by build: the package is gone) |
|
||||
| A container needs the seat held | A resolution test refusing a containerised assignment on a machine with the seat unheld, naming the seat |
|
||||
| Socket mounts are granted by the seat | A catalogue test: a module mounting the runtime's socket on a machine whose holder states a different path is refused |
|
||||
| No other module writes the runtime's file | The existing collision check, once the private network's computed resources are inside it ([issue 190](../04-ISSUES/190-the-runtimes-configuration-is-written-by-modules-that-are-not-the-runtime/00-report.md)) |
|
||||
| Live | `seats` lists `node-container-runtime` held on every machine; the node listing shows each machine's containers, strays included, from the seat's `list` verb; a container started by hand appears as an event on the bus |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md), [ADR 0129](0129-a-seat-carries-the-protocol-of-its-role.md), [ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md), [ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md), [ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md), [ADR 0161](0161-what-deserves-a-seat.md)
|
||||
- [ADR 0150](0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md), [ADR 0142](0142-the-mesh-delivers-its-own-components-as-binaries.md), [ADR 0078](0078-the-store-and-broker-are-modules.md), [ADR 0005](0005-the-node-host.md)
|
||||
- [ADR 0164](0164-a-setting-is-declared-with-its-default-its-meaning-and-what-changing-it-costs.md), [ADR 0165](0165-container-runtime-is-what-a-machine-can-run-and-a-running-runtime-is-its-holders-health.md), [issue 190](../04-ISSUES/190-the-runtimes-configuration-is-written-by-modules-that-are-not-the-runtime/00-report.md)
|
||||
- [Design 26 — the seats](../03-DESIGN/01-to-be/26-the-seats.md), [design 33 — the tools the mesh answers](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md)
|
||||
- mesh-host `internal/apply/apply.go` (the runtime lookup and the command line it drives)
|
||||
+99
@@ -0,0 +1,99 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md
|
||||
---
|
||||
|
||||
# 167. A membership carries what its module receives, and who the mesh is
|
||||
|
||||
## Context
|
||||
|
||||
A provider learns what it is given from a file. The controller composes every consumer's contribution
|
||||
to a requirement, and the node's declaration writes them into the provider's received file. The route
|
||||
proxy reads its routes that way: one JSON file, re-read every two seconds.
|
||||
|
||||
[Issue 191](../04-ISSUES/191-a-route-with-only-an-internal-name-is-dropped/00-report.md) showed what
|
||||
that file leaves out. Since [ADR 0138](0138-an-assignment-binds-an-endpoint-and-says-how-far-it-reaches.md),
|
||||
a route whose endpoint reaches only the private network carries an internal name and no public one.
|
||||
The proxy dropped it. Serving it was not enough either: the proxy answers public and internal names on
|
||||
the same listeners, so an internal name served to every request is public under a guessable name. To
|
||||
serve it correctly the proxy needs a second fact, **who the mesh is**, and nothing gave it one.
|
||||
|
||||
The first attempt had the proxy work it out: the mesh's range from an environment variable written by
|
||||
the catalogue, and the machine's container bridges read from its own interfaces. That is a second
|
||||
definition of "the mesh", kept by one module, beside the one the packet filter already uses. The
|
||||
controller resolves "from the mesh" to every machine's address on the private network, and the filter
|
||||
is rendered from that list. Two definitions agree until one changes.
|
||||
|
||||
[ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md)
|
||||
already gives every assignment one document on the bus, its membership, read once at connect and
|
||||
followed. It says what the assignment serves and reaches. It does not yet say what it is given.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep the file, add the mesh to it.** The proxy keeps polling a file, and the controller writes the
|
||||
mesh's addresses beside the routes. It fixes the definition, but delivery stays a file re-read on a
|
||||
timer, written by a separate path from the one every other fact a module is told now takes.
|
||||
2. **Have the proxy work it out** from a range in its environment and the machine's interfaces. Rejected:
|
||||
it is the second definition this record exists to remove.
|
||||
3. **The membership carries it.** What each module receives, from the same composition its received
|
||||
file is written from, and the mesh's addresses, from the same list the filter is rendered from. The
|
||||
proxy follows its membership and serves exactly that.
|
||||
|
||||
## Decision
|
||||
|
||||
**Option 3.**
|
||||
|
||||
- **A membership carries what its module receives**, by requirement: the contributions every consumer
|
||||
made, exactly as composed for its received file. A requirement nobody contributed to is an empty
|
||||
list, never absent, for the reason the file is written empty: "nothing asked" and "never told" want
|
||||
different responses.
|
||||
- **A membership carries who the mesh is**: every machine's address on the private network, the list
|
||||
a rule saying "from the mesh" resolves to. One list, two readers: the filter and any module that
|
||||
must tell the mesh from the world.
|
||||
- **The route proxy reads its routes and the mesh from its membership**, with the bus account every
|
||||
module that speaks on the bus is given. It serves an internal name only to the machines the mesh
|
||||
names and to the machine itself, and answers anyone else as it answers a name it never routed: in
|
||||
the request, in the handshake, and in the list of names it serves.
|
||||
- **The file stays until the bus has spoken.** While a proxy has read no membership that carries routes,
|
||||
it serves the file, and an internal name only to its own machine: refused, never opened. A
|
||||
membership from a controller that issues no routes changes nothing.
|
||||
|
||||
## Consequences
|
||||
|
||||
- Every membership grows two fields. A machine joining or leaving republishes every membership, which
|
||||
a push already does.
|
||||
- A provider that receives something is told it twice for now, in its file and on the bus. The file
|
||||
goes when every provider reads its membership; that is its own change.
|
||||
- The route proxy needs a bus account. It is issued like any module's, so a machine running the proxy
|
||||
cannot be composed between the catalogue declaring the account and the operator issuing it. The
|
||||
machine keeps what it runs meanwhile.
|
||||
- The internal name of a route that also has a public one is now served to the mesh only. Outsiders
|
||||
have the public name.
|
||||
- A container on the same machine that calls that machine's own internal name arrives from its
|
||||
container network, not from a mesh address, and is refused. Calls between machines are unaffected:
|
||||
they leave by the machine's mesh address. Whether the mesh should also issue each machine's container
|
||||
networks is left open, because the mesh does not record them today.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| What a provider receives on the bus is what its received file says, same-node port fix included | a controller test composing a provider and a consumer on one machine and comparing the two |
|
||||
| An internal name is served to the machines the membership names and to loopback, and to nobody else | the proxy's tests: served from a named address and from loopback; refused, unlisted and uncertified from any other |
|
||||
| A membership that carries no routes, or a mesh that cannot be read, changes nothing | the proxy's tests |
|
||||
| Until the mesh is issued, an internal name is served to the machine alone | the proxy's tests |
|
||||
| Live: an internal-only route answers over the mesh and is refused from outside | by hand, after the release |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md) —
|
||||
the membership this extends
|
||||
- [ADR 0138](0138-an-assignment-binds-an-endpoint-and-says-how-far-it-reaches.md) — reach, and the
|
||||
insight of 2026-10-02 that the proxy is where internal reach is kept
|
||||
- [ADR 0144](0144-anything-on-a-machine-may-call-anything-on-it.md) — the machine itself is always inside
|
||||
- [Issue 191](../04-ISSUES/191-a-route-with-only-an-internal-name-is-dropped/00-report.md) — what
|
||||
found it
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0100-a-node-in-use-is-adopted-before-it-is-converged.md
|
||||
---
|
||||
|
||||
# 168. A converged machine is filtered by the mesh alone, and the host says what else refuses
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md) says what converging does to
|
||||
the firewall a machine was found with: the mesh's derived filter is loaded in place of the
|
||||
refusal-only guard, and the found firewall is retired — disabled, never flushed. Four issues from
|
||||
the first two convergences are four ways that sentence was not the machine:
|
||||
|
||||
- the flip reported the found firewall retired and it was active two minutes later; fifty minutes
|
||||
on, a reconcile found it disabled by hand and recorded that the mesh had done it
|
||||
([143](../04-ISSUES/143-converging-does-not-retire-the-firewall-it-found/00-report.md));
|
||||
- "the firewall found" named one front end, and what filtered the forwarded path on that machine
|
||||
was a chain a predecessor had installed in the container runtime's user hook — invisible to the
|
||||
mesh, refusing two ports the mesh declared open, and when it was removed, carrying an allowance
|
||||
every module reaching another by the machine's own name had been relying on
|
||||
([144](../04-ISSUES/144-the-predecessors-rules-outlive-the-firewall-it-was-found-as/00-report.md),
|
||||
[145](../04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md));
|
||||
- the forward chain listed address ranges that followed neither the modules nor the machine
|
||||
([141](../04-ISSUES/141-the-forward-chain-does-not-follow-the-modules/00-report.md)), answered by
|
||||
[ADR 0140](0140-the-filter-constrains-what-arrives-from-outside.md) before this record;
|
||||
- the networking module wrote two machine-wide files whole, so taking it restarted every
|
||||
container ([084](../04-ISSUES/084-taking-networking-on-an-adopted-node-restarts-every-container/00-report.md)),
|
||||
answered by [ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md) and the hosts
|
||||
file's marked region ([issue 128](../04-ISSUES/128-the-hosts-file-is-written-whole/00-report.md)).
|
||||
|
||||
Read on the four machines of this mesh on 2026-10-02, after every one had converged: on both
|
||||
machines that had a front end it is inactive, and the host's record says the mesh retired it on
|
||||
both — true of one, false of the other. On the home server the predecessor's chain is still in
|
||||
force on the forwarded path, in the legacy packet filter the mesh's reader of rules does not
|
||||
consult once a machine is converged, so that machine is filtered by two things and the mesh says
|
||||
one. The host's reader already knows how to tell a table that refuses traffic from the runtime's
|
||||
own plumbing and from a ban list; it is asked once, at adoption, and only to refuse a machine
|
||||
whose firewall nobody speaks. Nothing asks it afterwards, and nothing reports what it saw.
|
||||
|
||||
The group's exit is one sentence: *a converged machine has exactly one thing filtering it, and
|
||||
the mesh says truthfully which.* The first half the mesh can enforce only for what it owns; the
|
||||
second half it can always do, and it is the half that was missing.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. Convergence is a state the host keeps, not a step it takes once.** Every apply of a converged
|
||||
declaration reads whether the found firewall is in force. Active — enabled again by a package, a
|
||||
boot, a hand — it is retired again and said. The record distinguishes *the mesh disabled it* from
|
||||
*it was found inactive*, and a reconcile that finds it inactive never records that the mesh did
|
||||
it. When the step is skipped because the apply had failures, the report says the found firewall
|
||||
was left in force and why; a step that does nothing is never silent.
|
||||
|
||||
**2. The host reports what filters the machine, with every apply, adopted or converged.** Every
|
||||
table of the packet filter, and every chain of the legacy filter, that refuses traffic — a drop or
|
||||
a reject, or a base chain whose policy drops — with an owner: the *mesh's*, the *found firewall's*,
|
||||
the *container runtime's own*, a *ban* (a refusal that names the sources it refuses, in a chain
|
||||
that accepts nothing), or *other*. The runtime's own is its plumbing — its chains, the forward
|
||||
policy it sets when it turns forwarding on, its guard against reaching a container's address from
|
||||
off its bridge. The user chain the runtime leaves for an administrator is not the runtime's:
|
||||
anything refusing in it is *other*, which is where both predecessors' chains lived. Each entry
|
||||
says in one line what it refuses. The mesh removes none of it: a rule it did not write is the
|
||||
operator's to remove, now that they can see it.
|
||||
|
||||
**3. The mesh says which.** `node show` lists the filters with their owners. `status` names every
|
||||
converged machine that something other than the mesh's table, the runtime's plumbing and a ban
|
||||
list filters, the way it names strays and untaken modules, and such a machine is not "all well".
|
||||
The converge preview lists the filters found and the fate of each: the found firewall retired, the
|
||||
runtime's and the bans left, *other* left and named — so a person knows before the flip that the
|
||||
machine will not be filtered by the mesh alone until they remove it, and what they would be
|
||||
removing. *A converged machine is filtered by the mesh alone* when its list holds nothing but the
|
||||
mesh's, the runtime's own and bans.
|
||||
|
||||
**4. Adoption's threshold does not move.** A machine whose front end nobody speaks is still refused
|
||||
adoption; a refusing rule in the runtime's user chain still does not refuse it — on both machines
|
||||
of this mesh it would have, and the migration would not have happened. It is reported instead,
|
||||
from the first report on.
|
||||
|
||||
**5. Two of the group's issues are settled by records already accepted.** The forward chain follows
|
||||
the machine's outward links and says nothing about networks ([ADR 0140](0140-the-filter-constrains-what-arrives-from-outside.md)),
|
||||
which answers 141 whole. The runtime's file is written into and reloaded, and the hosts file's
|
||||
region is the mesh's alone ([ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md),
|
||||
[issue 128](../04-ISSUES/128-the-hosts-file-is-written-whole/00-report.md)), which answers 084. One
|
||||
machine-wide file the mesh still writes whole is its own filter, at the path the distribution's
|
||||
packet filter reads; an operator's own rules at that path would be contested, and are held as
|
||||
found until the filter module is taken ([ADR 0163](0163-taking-a-module-over-is-a-comparison.md)).
|
||||
That is a difference a take shows, not a fault, and is decided when it bites.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The host's report grows by the filters it found and, for a converged machine, the state of its
|
||||
found firewall and who retired it; the controller keeps both on the node's record.
|
||||
- `retireFirewall` runs on every converged apply and can disable the found firewall more than
|
||||
once; the record's *disabled by the mesh* means exactly that.
|
||||
- The reader of rules gains an owner per table and chain; what it refuses adoption for does not
|
||||
change. A ban stays what it was: not a firewall.
|
||||
- Issues 143 and 144 close on rules 1 to 3 once a machine's record names the predecessor's chain;
|
||||
141 closes on ADR 0140 and 084 on ADR 0102, both by reading.
|
||||
- Removing what is reported is the operator's act, by hand, with the preview's words in front of
|
||||
them. The mesh never flushes and never deletes a rule it did not mark.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| Every refusing table and chain is classified, the user chain's refusals as *other* | host tests over rulesets captured from three machines of this mesh: a predecessor's chain in the legacy filter, a ban list and empty front-end chains beside the runtime's, a virtualisation host and an endpoint agent that refuse nothing |
|
||||
| The found firewall active again on a converged machine is retired again and said; found inactive is recorded as found, not done; a skipped step is said | host tests over a fake front end |
|
||||
| The report carries the filters and the found firewall's state for a converged machine | a host test reading the report |
|
||||
| `node show` lists filters with owners; `status` names a converged machine something else filters and is not well; the preview lists filters and fates | controller tests over a fixture report |
|
||||
| Live | the home server's record names the predecessor's chain in the runtime's user chain as *other*; `status` names the machine; after the operator removes the chain, the next report drops it and `status` is well |
|
||||
|
||||
## Built and proven live, 2026-10-02
|
||||
|
||||
> **Progressive insight — 2026-10-02.** The decision stands; these are the facts of its building.
|
||||
|
||||
Built in mesh-host 67 (every refusing table and legacy chain classified with an owner, reported with
|
||||
every apply; the found firewall retired on every converged apply, *found inactive* kept apart from
|
||||
*disabled by the mesh*, a skipped step said) and mesh-controller 211 (kept per node, shown on `node
|
||||
show`, named by `status` and not well, previewed with fates). The live row was read at 10:10Z: the home
|
||||
server's record named the predecessor's chain in the legacy filter's user chain as *other*, beside two
|
||||
chains a retired front end left in the IPv6 legacy filter; the control node's record named the same two
|
||||
leftovers; the laptop and the workstation read *the mesh alone*; `status` named both machines. The five
|
||||
rule sets were removed at 12:46Z through the packet filter seat's `remove` verb
|
||||
([ADR 0170](0170-the-firewall-seat-serves-its-verbs.md)), and the next report read *the mesh alone* on
|
||||
all four machines. The control node's record still says the mesh retired its front end, which issue 143
|
||||
records as a hand's work: the host trusts its record, and from this build on the distinction is kept.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md), [ADR 0103](0103-what-an-adopted-node-holds-and-what-its-guard-refuses.md), [ADR 0140](0140-the-filter-constrains-what-arrives-from-outside.md), [ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md), [ADR 0163](0163-taking-a-module-over-is-a-comparison.md)
|
||||
- [Design 08 — Connectivity](../03-DESIGN/01-to-be/08-connectivity.md), [Design 05 — The node host](../03-DESIGN/01-to-be/05-the-node-host.md)
|
||||
- Issues 084, 141, 143, 144, 145
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0004-a-node-and-how-it-joins.md
|
||||
---
|
||||
|
||||
# 169. A machine joins through the tunnel, and the bus is never public
|
||||
|
||||
## Context
|
||||
|
||||
The bus is the one channel every machine depends on: enrolment, every declaration, every tool. The
|
||||
`nats` module declares it reachable from the mesh only. The controller still opens it to the whole
|
||||
internet on the machine that runs it, as a *foundation* port that no module declares and nothing may
|
||||
close ([issue 051](../04-ISSUES/051-the-mesh-cannot-update-what-it-depends-on/00-report.md)).
|
||||
The reason is joining. [ADR 0004](0004-a-node-and-how-it-joins.md) has a new machine enrol over the bus
|
||||
**before** it has a tunnel. [ADR 0007](0007-connectivity.md) states it as a requirement: the node
|
||||
running the broker must be reachable from wherever nodes are, at a stable address.
|
||||
|
||||
So the bus listens on the internet permanently, for an event that happens a few times a year. A
|
||||
sweep of every machine on 2026-10-02 found no client using the public path. Every connection arrives
|
||||
over the tunnel or from the machine itself. The join token does not use it either: it carries the
|
||||
controller's configured broker address, a mesh name with the old broker's port.
|
||||
|
||||
ADR 0004 already says what a joining machine needs: *an identity, an address, and one peer to reach*.
|
||||
The tunnel can be that peer, if the hub knows the new machine's key before the machine first knocks.
|
||||
WireGuard answers nothing to a key it does not know, which is why the tunnel's own port is safe to
|
||||
leave open where the bus's is not.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep the bus public.** It is authenticated and encrypted, but every exposure of it, and of the
|
||||
server behind it, is exposure of the one thing everything depends on.
|
||||
2. **Open the bus publicly only while a join token is live.** Small, and the hub is open only during a
|
||||
join window. But the window is real, the rule is about time rather than about who may reach the
|
||||
bus, and the opening and closing are pushes that can fail between them.
|
||||
3. **The controller makes the new machine's tunnel key and puts it in the token.** One step for the
|
||||
operator, but the private half leaves a machine it does not belong to. ADR 0004 refuses that for
|
||||
every key a node holds.
|
||||
4. **The machine makes its key first, and the token is issued for it.** The machine prints the public
|
||||
half of its tunnel key. The operator issues the token for that key. The controller gives the
|
||||
machine its address and adds it as a peer on the hub. The token carries the hub's tunnel endpoint
|
||||
and key, the machine's address, and the bus's address on the private network. The machine brings
|
||||
up its tunnel and enrols over it.
|
||||
|
||||
## Decision
|
||||
|
||||
**Option 4.**
|
||||
|
||||
- **A machine makes its own tunnel key before it has a token**, and prints the public half. The private
|
||||
half never leaves it, as ADR 0004 says of every key a node holds.
|
||||
- **A token is issued for a tunnel key.** Issuing it assigns the machine's address on the private
|
||||
network, records the key, and makes the machine a peer of the hub. The hub is sent that before the
|
||||
token is shown, so the tunnel answers the moment the machine first uses it.
|
||||
- **The token carries the one peer.** It adds the hub's tunnel endpoint and public key and the
|
||||
machine's own address. **Where** becomes the bus's address on the private network, which needs no
|
||||
name resolution.
|
||||
- **The machine joins through the tunnel.** It brings the tunnel up from the token alone, then enrols
|
||||
over it exactly as before. The enrolment checks that the key it is offered is the one the token was
|
||||
issued for.
|
||||
- **The bus is never public.** It is no longer a foundation port. Its reach is what the `nats` module
|
||||
declares: the mesh. The tunnel's port stays open, as the one way in.
|
||||
|
||||
This changes three things earlier records say. ADR 0004's *where* is the bus's private address, and the
|
||||
token carries the peer. ADR 0007's requirement that the broker be reachable from wherever nodes are
|
||||
becomes: **the hub's tunnel is**. Issue 051's broker port stops being a foundation port.
|
||||
|
||||
## Consequences
|
||||
|
||||
- Joining is two commands on the new machine, with the token issued between them. A token issued for
|
||||
the wrong key gives a tunnel that never answers, and the machine says so rather than timing out at
|
||||
the bus.
|
||||
- An unused token leaves a peer on the hub until it expires. Expiry removes it, the same way it voids
|
||||
the secret.
|
||||
- A machine already in the mesh is unaffected: it reaches the bus over its tunnel today.
|
||||
- The genesis machine, the first one, raises the bus on itself and needs no tunnel to reach it.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A token is refused without a tunnel key, and carries the hub's peer and the machine's address | a controller test |
|
||||
| Issuing a token makes the machine a peer of the hub before the token is shown | a controller test over the hub's composed tunnel |
|
||||
| An expired, unused token's peer is gone from the hub | a controller test |
|
||||
| Enrolment refuses a tunnel key other than the one the token was issued for | a controller test |
|
||||
| No machine's filter opens the bus to anywhere | a controller test over the composed filter, and the live sweep from outside the mesh |
|
||||
| A new machine joins from outside the hub's network with the bus closed to it | the lab, then by hand |
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0168-a-converged-machine-is-filtered-by-the-mesh-alone.md
|
||||
---
|
||||
|
||||
# 170. The firewall seat serves its verbs, and a foreign rule set is removed through one of them
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md) made the mesh say truthfully
|
||||
what filters a converged machine, and left the removal of what it did not write to the operator's
|
||||
hand. The first time that hand was needed — two machines, five rule sets a predecessor and a
|
||||
retired front end had left — there was no mesh way to lend it: the packet filter is a seat
|
||||
([ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md)), a seat's
|
||||
holder serves its verbs ([ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md),
|
||||
[ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md)), and the
|
||||
firewall seat declared none. The only remaining path was a shell on the machine, which is the path
|
||||
the mesh exists to replace, and which the operator's own tooling rightly refused to an agent.
|
||||
|
||||
A seat's verbs are the contract every holder implements, whatever filter it speaks. What a person
|
||||
asks a machine's packet filter is the same whether nftables, a front end or a legacy filter answers:
|
||||
what are the rules, reload the mesh's own, remove this thing the mesh did not write. What differs by
|
||||
filter is the holder's own business and may be its own tools beside the seat's.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. The `node-packet-filter` seat serves three verbs**, and a module that claims it serves all
|
||||
three or is refused the claim, as with every seat:
|
||||
|
||||
- `rules` — the packet filter as the machine enforces it now: the nftables ruleset, and the legacy
|
||||
filter's listings where that tool exists; narrowed to one table or chain when asked. Read-only.
|
||||
- `reload` — load the mesh's own filter again from the file the mesh writes, and answer with the
|
||||
mesh's table as loaded. The holder's own act on the holder's own rules.
|
||||
- `remove` — remove one rule set the mesh did not write, named exactly as the host reports it under
|
||||
ADR 0168 (`chain HAL-MESH-ONLY (iptables-legacy)`, `table ip6 filter, chain DOCKER-USER`), and
|
||||
answer with what was done. It refuses the mesh's own tables, the container runtime's own chains,
|
||||
a built-in chain other than the runtime's user chain, and any chain of a found firewall that is
|
||||
in force. The runtime's user chain is emptied back to its one return; another chain loses the
|
||||
jumps into it, is flushed and deleted; a table of the machine's own is deleted whole. Each is an
|
||||
operator's act, by name, on one thing the mesh reported — never a flush, never a rule the mesh
|
||||
itself marked.
|
||||
|
||||
**2. A holder may serve its own tools beside the seat's.** The nftables module keeps its reading of
|
||||
the mesh's table as its own tool, and a holder speaking a filter with specifics of its own may add
|
||||
tools for them; the seat's three are what every holder owes.
|
||||
|
||||
**3. A container may ask for a capability.** Serving `remove` and `reload` needs the machine's
|
||||
network namespace and the right to change its packet filter; a holder's runtime declares
|
||||
`capabilities: ["NET_ADMIN"]` on its container and runs on the machine's network. The host grants
|
||||
exactly the capabilities declared, names them in the container's spec so a change recreates it, and
|
||||
refuses a name that is not a capability's. A privileged container stays undeclarable.
|
||||
|
||||
**4. ADR 0168's "by hand" is read as "by the operator, through the seat".** Removing what the mesh
|
||||
reports as *other* is still the operator's act and is still never the mesh's own doing; the verb is
|
||||
how the act reaches the machine, recorded on the bus like every other, instead of a shell.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The seat's row gains the three verbs; a mesh that already runs widens its row at the next
|
||||
controller start. The nftables module claims them and gains a runtime — a tool server with the
|
||||
packet filter's tools in its image, on the machine's network, with `NET_ADMIN`.
|
||||
- The host's container vocabulary grows by `capabilities`; an older host refuses a declaration that
|
||||
carries it, so the host rolls before the module.
|
||||
- The two machines of this mesh that ADR 0168 found not filtered by the mesh alone are cleaned
|
||||
through `remove`, and read *the mesh alone* afterwards; `status` returns to well without a hand on
|
||||
either machine.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| The seat declares the three verbs; a claim that serves fewer is refused by name | the catalogue's seat tests |
|
||||
| `remove` refuses the mesh's tables, the runtime's chains, a built-in chain and an active front end's chains, and removes a user chain with its jumps, empties the user chain, deletes an own table | the module's tests over a fake command runner, with the shapes the host reported live |
|
||||
| A container's capabilities reach the runtime and its spec; an unknown name is refused | host tests |
|
||||
| Live | `node-packet-filter.remove@<node>` on the home server and the control node; `node show` reads *the mesh alone* on both; `status` is well |
|
||||
|
||||
## Built and proven live, 2026-10-02
|
||||
|
||||
> **Progressive insight — 2026-10-02.** The decision stands; these are the facts of its building.
|
||||
> Written as 0169 for three hours and renumbered to 0170: another record took 0169 on main first,
|
||||
> and the check that refuses a shared number covered issues only (now records too).
|
||||
|
||||
Built in mesh-host 68 (`capabilities` on a container), mesh-controller 212 (the seat's three verbs)
|
||||
and 213 (the filter file a module names under `filtering.into` counts as declared for a mount — the
|
||||
module's first build was refused without it), mesh-catalog 216 (the nftables module's runtime and
|
||||
verbs) and mesh-tools 27 (the console lists a node-scoped seat's verbs with their scope and carries the
|
||||
machine; before it, the verbs were live on four machines and unreachable from the console —
|
||||
[issue 199](../04-ISSUES/199-a-node-scoped-seats-verb-could-not-be-called-through-the-console/00-report.md)).
|
||||
Each machine's holder was issued its bus account with `mesh-controller.issue`, the broker node pushed
|
||||
first. At 12:46Z the five rule sets ADR 0168 had named were removed through
|
||||
`node-packet-filter.remove`, three on the home server and two on the control node, each answering
|
||||
with the commands it ran; the next report read *the mesh alone* on all four machines and `status`
|
||||
listed nothing under `filtered`. The live row is read. What it cost on the way is
|
||||
[issue 200](../04-ISSUES/200-the-controllers-answer-to-the-console-is-refused-by-the-bus/00-report.md).
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md), [ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md), [ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md), [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md)
|
||||
- [Design 33 — The tools the mesh answers](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md), [Design 08 — Connectivity](../03-DESIGN/01-to-be/08-connectivity.md)
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0016-the-lab.md
|
||||
---
|
||||
|
||||
# 172. The lab is a module, and runs a bed when the mesh asks
|
||||
|
||||
## Context
|
||||
|
||||
The lab raises virtual machines and runs the mesh on them, end to end, before a change reaches a real
|
||||
machine ([ADR 0016](0016-the-lab.md)). It runs on one machine of the mesh, the one with the
|
||||
virtualisation it needs. Until now the only way to start a bed there was to sign in to that machine and
|
||||
run the lab's command line by hand, with a dozen environment variables pointing at sibling checkouts.
|
||||
|
||||
Nothing in the mesh could ask for it. An agent working through the mesh's own tools could build,
|
||||
merge and push a change, and could not prove it in the lab first. The operator's direction on
|
||||
2026-10-02: work on another machine goes through a mesh tool, not a shell on it.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep the lab a command line on one machine.** Every run is a person, or an agent with a shell on
|
||||
that machine, outside the mesh.
|
||||
2. **The lab is a module.** Assigned to the machine that can run it, serving tools that run a bed
|
||||
against named branches and say how it went.
|
||||
|
||||
## Decision
|
||||
|
||||
**Option 2.**
|
||||
|
||||
- **A `lab` module, assigned where the lab can run**, serves five tools: whether this machine can run
|
||||
beds, run beds against a branch per repository, a run's state, its log, and stopping it.
|
||||
- **A run is the lab's own suite**, against fresh checkouts of the named branches from the mesh's forge,
|
||||
side by side as the lab expects them. It builds what the beds place from those checkouts, as the suite
|
||||
already does. It answers at once with an id, like a build: a bed takes minutes, and a call does not.
|
||||
- **Only branches on the forge are run**, never code handed to the tool. What a run tested is what the
|
||||
forge holds at the commit it names.
|
||||
- **The lab is reached over the mesh only.** Its tools travel the bus, and the module opens no port.
|
||||
- **No grant beyond the mesh's own.** Running a bed is root on the lab's machine, but anyone who can call
|
||||
the mesh's tools can already do worse. The operator's judgement on 2026-10-02.
|
||||
|
||||
## Consequences
|
||||
|
||||
- An agent proves a change in the lab through the mesh, the same way it builds and pushes one.
|
||||
- The lab's machine carries a module whose runtime holds the virtualisation's and the container
|
||||
runtime's sockets, and a toolchain to build the mesh with.
|
||||
- A run's checkouts are its own, so two runs never build from each other's tree. Old ones are removed
|
||||
when their run ends.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A run checks out exactly the named branches, and reports the commits it tested | the module's tests over a forge fixture, and each run's answer |
|
||||
| A run answers at once, and its state and log follow it to the end | by hand, the first run |
|
||||
| The module opens no port | the composed filter of the lab's machine |
|
||||
+108
@@ -0,0 +1,108 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0040-what-a-module-is.md
|
||||
---
|
||||
|
||||
# 173. The operator's machine is the mesh's, and a module is whatever it declares
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0040](0040-what-a-module-is.md) says a module is *one self-contained piece of software the
|
||||
mesh installs and manages*, and every example it gives is a service: a database, an analytics
|
||||
server, a forge. The catalogue followed the examples. Of the predecessor's 34 modules on one
|
||||
workstation, 28 are the operator's environment — a login manager, a window manager with 88 files
|
||||
and four flavors, a shell, a terminal, a launcher, an audio setup, scripts — and the migration
|
||||
scoped all 28 out as *the workstation's own environment*, to be managed by nobody
|
||||
([research 018](../01-RESEARCH/018-the-operators-machine-as-modules/02-what-exists-and-what-is-missing.md)).
|
||||
Since the predecessor retired, nobody is exactly who manages them: a fix is a hand edit that
|
||||
nothing records and nothing regenerates.
|
||||
|
||||
[To-be 29](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) reached under the home for
|
||||
one directory and drew a boundary inside it. The operator's statement is wider: *the mesh manages
|
||||
my entire machine, all four of them, as far as it makes sense* — system folders and the home
|
||||
alike, the servers and the workstations from the same catalogue. And the operator refused a
|
||||
distinction this effort first drew between modules that ship code and modules that ship only
|
||||
declarations: *a module can have some tools, a seat implementation, some containers, a unit, a
|
||||
binary, some config files — one of these, or all, or two.*
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep 0040's reading and manage the environment outside the catalogue** — dotfiles in a
|
||||
repository, a script that places them. Rejected: that is the predecessor's first two days, the
|
||||
origin of every inherited shape [as-is 10](../03-DESIGN/00-as-is/10-module-catalogue.md)
|
||||
documents, and it puts the one thing a person looks at outside the one mechanism that is
|
||||
checked.
|
||||
2. **Add a second kind of module for configuration** — a "config module" with files and no
|
||||
process. Rejected by the operator: a kind is a distinction the manifest already makes by what
|
||||
it declares, and a second kind is a second set of rules to keep in step.
|
||||
3. **One definition: a module is one managed thing, described by what it declares.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. Everything configurable on a node is declared by a module.** Services, and equally the login
|
||||
manager, the display server, the window manager, the shell, the terminal, the launcher, the
|
||||
notifier, the audio setup, the boot images, the package manager's configuration, the agent at the
|
||||
terminal, and a folder a person works in. The test is *can it be configured on a machine*; if it
|
||||
can, some module owns it. What no module declares is found and left alone, as adoption already
|
||||
says of a machine ([ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md)).
|
||||
|
||||
**2. A module is whatever it declares, and there are no kinds of module.** A package, files, a
|
||||
container, a unit, a binary, a seat claim, tools — any one, or all. 0040's *one self-contained piece
|
||||
of software* stands; its examples were services, and that was the whole of the bias. A downloads
|
||||
folder with a process that tidies it, backs it up and answers questions about it is a piece of
|
||||
software by 0040's own test, and so is a shell that is a package, three files and a seat.
|
||||
|
||||
**3. The home has no boundary of its own.** A file under the operator's home is placed and owned
|
||||
the way [to-be 29](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) §2 built it: by a
|
||||
module, resolved against the account's home, owned by the account. Which files are the mesh's is
|
||||
decided by what modules declare, not by a line drawn through a directory. A person's documents,
|
||||
projects and history are data under [ADR 0051](0051-shared-data-is-the-operators.md) and no module
|
||||
declares them.
|
||||
|
||||
**4. One module ships one default configuration.** No flavors. What differed between the
|
||||
predecessor's four flavors of one desktop module is what [ADR 0174](0174-a-node-varies-a-module-through-settings-and-kept-regions-never-an-edit.md)
|
||||
is for.
|
||||
|
||||
**5. Servers and workstations take the same catalogue.** A module declares what it needs; a
|
||||
machine reports what it has; assignment refuses by name
|
||||
([ADR 0161](0161-what-deserves-a-seat.md) §3). The shell, the prompt, git and the agent are universal.
|
||||
A display server needs a graphical session; a window manager needs the display server held. Nothing
|
||||
in a manifest says *workstation*.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The catalogue grows by a family of modules that run no service. Each is still built,
|
||||
registered, assigned, pushed and reported like every other, and `status` says whether a
|
||||
machine has applied them.
|
||||
- The account fact becomes load-bearing for every node a person uses. Today it is empty on all
|
||||
four node records of this mesh; stating it is the first step of the build.
|
||||
- A module that *installs* a thing is distinct from a module that *holds its role*: zsh, fish and
|
||||
bash may all be installed, and one holds the login shell
|
||||
([ADR 0176](0176-the-login-shell-is-a-node-seat-and-execute-is-its-contract.md)).
|
||||
- The host's `package` shape drives the distribution's package manager only. A module whose
|
||||
package is outside the distribution's repositories — the login manager in use is one — needs
|
||||
either an official package or a shape the host does not have. Recorded as a gap, not decided.
|
||||
- The predecessor's hooks go. What they did becomes declared state the host applies, or a verb a
|
||||
seat serves ([ADR 0177](0177-a-unit-may-be-user-scoped-and-the-service-manager-is-a-node-seat.md)).
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A manifest with no container, no unit and no binary registers and resolves like any other | the catalogue's registration tests, with a package-and-files manifest |
|
||||
| A file resource under the home resolves against the account and is owned by it | the controller's composition tests (to-be 29 §2, built) |
|
||||
| A home-scoped module is refused on a node with no account, naming the fact | the same tests |
|
||||
| A module needing a capability the machine lacks is refused by name | the resolver's tests (ADR 0161 §3) |
|
||||
|
||||
## References
|
||||
|
||||
- [Research 018](../01-RESEARCH/018-the-operators-machine-as-modules/00-overview.md), documents
|
||||
01 and 02 — the behaviour wanted and the inventory measured.
|
||||
- [ADR 0040](0040-what-a-module-is.md), [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md),
|
||||
[ADR 0051](0051-shared-data-is-the-operators.md), [ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md)
|
||||
- [To-be 29](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) — the account and the home
|
||||
as a placement root, built; the records for them are proposed in an open change.
|
||||
+92
@@ -0,0 +1,92 @@
|
||||
---
|
||||
topic: building it
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0011-managed-files-are-generated-never-edited.md
|
||||
---
|
||||
|
||||
# 174. A node varies a module through settings and kept regions, never through an edit
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0011](0011-managed-files-are-generated-never-edited.md) says a managed file is derived and an
|
||||
edit to it is overwritten without warning. The predecessor said the same and then undid it twice:
|
||||
a `merge` strategy that adopted disk drift back into its database, so a local edit became the
|
||||
record; and a theming layer of about 90 environment variables substituted into templates at sync
|
||||
time, with tools to list and set them, so that *nearly every value was a variable* — a second
|
||||
configuration language laid over the first.
|
||||
|
||||
The operator wants both the variation and the rule. One window-manager module with one default
|
||||
configuration, and each node tweaking it; and the file carrying the wanted value rather than a
|
||||
variable the file reads. Two mechanisms already exist for exactly this: a **setting**, declared by
|
||||
the module and set per mesh or per node, rendered at composition
|
||||
(`${setting:…}` is live in the resolver's manifest); and a **kept region**, a block in a file the
|
||||
mesh writes *into* where the operator's own lines survive every push
|
||||
([ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md), used by the ssh-client module
|
||||
for the operator's own `Host` blocks).
|
||||
|
||||
What stands in the way is [issue 168](../04-ISSUES/168-a-setting-reaches-every-file-and-contribution/00-report.md):
|
||||
a setting today reaches every mergeable file and every contribution of its module. Ninety theme
|
||||
knobs on that mechanism would reach ninety files. The record that fixes it — a setting declared
|
||||
with its type, meaning, default and the file it lands in — is proposed in an open change alongside
|
||||
the container-runtime records.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Carry the predecessor's merge strategy.** A local edit is adopted into the node's layer.
|
||||
Rejected: two writers and no arbiter, which is the option 0011 removed, and the reason a
|
||||
`/model` choice was silently reverted on every node for weeks before anyone found the cause.
|
||||
2. **Carry the environment-variable theming.** Rejected by the operator: the value belongs in
|
||||
the file; a variable the file reads is a second place for the same fact.
|
||||
3. **A per-node file override** — a whole file replaced for one node. Rejected: it is a flavor
|
||||
under another name, and a module update then misses that node entirely.
|
||||
4. **Settings rendered into the file, and kept regions, and nothing else.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**A node varies a module in exactly two ways.**
|
||||
|
||||
- **A setting.** Declared by the module with a default, set for the mesh or for one node, rendered
|
||||
into the file at composition. The value is in the file. Asked, the mesh lists every setting
|
||||
with its effective value and where it came from.
|
||||
- **A kept region.** A marked block in a file the mesh writes into, in which the operator's own
|
||||
lines are kept across every push and given back when the module goes (ADR 0102).
|
||||
|
||||
**An edit outside a kept region is overwritten, as ADR 0011 says, and never adopted.** Nothing
|
||||
reads a managed file back into the record.
|
||||
|
||||
**The predecessor's theme knobs become settings** of the modules whose files they render — the
|
||||
window manager's colours are the window manager's settings, the bar's are the bar's — each
|
||||
landing in the file that reads it and no other.
|
||||
|
||||
**Issue 168 is fixed before any environment module declares a setting.** A setting must name the
|
||||
file it lands in; until that ships, the environment modules carry their defaults in their files
|
||||
and no settings.
|
||||
|
||||
## Consequences
|
||||
|
||||
- No flavors, no per-node file copies, no environment layer. A module's definition is one set of
|
||||
files; a node's difference is data in its layer, visible by asking.
|
||||
- The settings record proposed alongside the container-runtime records is on the critical path
|
||||
of every module with a knob, and this record depends on it shipping as proposed.
|
||||
- A kept region is the only place a person edits a managed file, and the file says where it is.
|
||||
The operator's own prompt customisations, aliases and window rules live there.
|
||||
- What got harder: a change that is neither a setting the module declared nor the operator's own
|
||||
lines has no home, and is refused by the mechanism rather than silently kept. That is the point.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A setting reaches only the file its declaration names | the controller's settings tests, once the proposed record ships; issue 168 closes on it |
|
||||
| A kept region survives a push with its content and is given back on undeclare | the host's write-into tests (ADR 0102), with a region declared by an environment module |
|
||||
| An edit outside a region does not survive a push | the same tests, asserting the file equals the composed content outside the region |
|
||||
| Every effective value names its source | `mesh-controller.settings` and the module's own `show-config` tool |
|
||||
|
||||
## References
|
||||
|
||||
- [Research 018](../01-RESEARCH/018-the-operators-machine-as-modules/01-the-intended-behaviour.md) §"One default, varied by settings, never by edits"
|
||||
- [ADR 0011](0011-managed-files-are-generated-never-edited.md), [ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md),
|
||||
[issue 168](../04-ISSUES/168-a-setting-reaches-every-file-and-contribution/00-report.md)
|
||||
+124
@@ -0,0 +1,124 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md
|
||||
---
|
||||
|
||||
# 175. One tool runtime per node serves every module's tools, on the host side
|
||||
|
||||
> **The mechanism changed — 2026-10-02, by [ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md).** Everything decided here stands: one runtime per node, host-side, every module's tools and every held seat's verbs on the memberships' subjects, root the module's concern, any node calls any tool, the console its serving mode. What moved is how the runtime brings a bundle to life. Decision 3 and the consequence *the node tools runtime needs an interpreter on the machine* read as though a bundle were always interpreted code the runtime imports; a tools bundle is now a process in any language that speaks MCP over stdio to the runtime, and importing a TypeScript bundle is the shortcut, not the contract.
|
||||
|
||||
## Context
|
||||
|
||||
A module's tools are code the module wrote, one function behind each verb, served on the subjects
|
||||
the controller issues in the module's membership
|
||||
([ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md)).
|
||||
What *runs* that code is [ADR 0150](0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md):
|
||||
a supervised process per module under the module's own account, and in the catalogue as built,
|
||||
that process is a container per module per node, built on the tool runtime's base image.
|
||||
|
||||
Measured on the live mesh ([research 018](../01-RESEARCH/018-the-operators-machine-as-modules/03-one-tool-executor-per-node.md)):
|
||||
67 module tools, each served from its module's container; the packet-filter seat's three verbs
|
||||
served by a container with `NET_ADMIN` on every one of four machines, for a module that is
|
||||
otherwise a package, three files and a service; and the console, a container per node, calling
|
||||
everything and serving nothing. The operator's environment adds a dozen modules of the
|
||||
packet-filter shape, and the operator's judgement is plain: *I would never run MCP tools inside
|
||||
a container; that is a very bad design.* And: *I don't care about permissions or account per
|
||||
module, that just complicates things for no good reason. Just a node-level tool executor. If a
|
||||
command needs root, that's the module's concern.*
|
||||
|
||||
The tool runtime itself was written for this. Its own description: *the per-node process that
|
||||
makes a module's tools actually serve — imports the assigned modules' compiled tool entrypoints,
|
||||
each of which registers its tools as it loads; on a node the host resolves the list and starts it
|
||||
like any other supervised workload.* What the catalogue did instead was build one image per module
|
||||
around it.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep a process per module.** Rejected: one container per module per node for software that
|
||||
is not a container, and the account-per-module invariant it exists to protect is one the
|
||||
operator declines to pay for.
|
||||
2. **The host executes tools itself.** Rejected: the host is a static Go binary that loads no
|
||||
plugins; a module's tools are TypeScript on the SDK, and building a second SDK in Go for the
|
||||
host's sake is the cost ADR 0039 refuses.
|
||||
3. **One tool runtime per node, a sibling of the host, loading every assigned module's bundle.**
|
||||
Chosen. It is what the runtime was written to be.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. One tool runtime per node, supervised by the host, on the host side — never a container.**
|
||||
The host starts it the way the launcher starts the host
|
||||
([ADR 0005](0005-the-node-host.md)): a process on the machine, restarted when it dies. It holds one
|
||||
bus credential, the node's. It is module-agnostic: it knows bundles and subjects, nothing of what
|
||||
any module does.
|
||||
|
||||
**2. It serves every assigned module's tools and every held seat's verbs** on the subjects the
|
||||
memberships issue. ADR 0159 and ADR 0160 are unchanged in what they say about subjects, grants
|
||||
and memberships; what changes is that one process on the node subscribes to all of them instead of
|
||||
one process per module. A module that runs a long-lived service of its own — a daemon, a
|
||||
container — keeps it; this record is about tools.
|
||||
|
||||
**3. A module brings its tools as a bundle**, the artifact kind the catalogue already has for
|
||||
interpreted code, built by the pipeline and delivered to the node by the host as it delivers any
|
||||
artifact. Never an image. The runtime loads each bundle as the membership names it, and a push
|
||||
that adds or replaces a bundle reaches a running runtime as a reload.
|
||||
|
||||
**4. Root is the module's concern.** A tool that must change the packet filter or rebuild boot
|
||||
images escalates itself. The runtime does not run as root for everyone's sake; the caller does not
|
||||
know and need not.
|
||||
|
||||
**5. Any node may call any tool on any node.** The runtime's credential may call everything, as
|
||||
the console's already may. A per-module calling grant is not kept.
|
||||
|
||||
**6. The console is this runtime's serving mode, renamed.** [ADR 0152](0152-the-operators-surface-is-a-module-the-console.md)
|
||||
stands in substance — a module assigned per node, MCP on the machine's loopback, the machine's
|
||||
login is the authority — and changes in form: host-side, serving as well as calling, and named for
|
||||
what it is: **node tools**. The mesh's own verbs stay with the controller
|
||||
([ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md)); a mesh-scoped seat's verbs
|
||||
run on the node that holds it ([ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md)).
|
||||
|
||||
**Where ADR 0047 and ADR 0150 say a module's tools are served by the module's own process under
|
||||
the module's own account, read this record.** Everything else they decided stands: a tool is served
|
||||
on its own subject, only the module that serves it answers, a module's long-lived processes are the
|
||||
machine's to supervise. The invariant 0150 kept — one account per module — no longer holds for
|
||||
tools, and the reason is stated above: every tool is callable from everywhere by decision 5, so the
|
||||
account no longer scopes anything a caller cannot already reach.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The packet-filter module's container goes; its verbs run on the host side and escalate as they
|
||||
need. [ADR 0170](0170-the-firewall-seat-serves-its-verbs.md) §3's container capability is moot
|
||||
for it.
|
||||
- The tool runtime's base image stays the way a module's *service* may be built; it is no longer
|
||||
the way tools reach a node.
|
||||
- The node tools runtime needs an interpreter on the machine. The module that is the runtime
|
||||
declares it as a package.
|
||||
- The container-runtime seat proposed in an open change says its holder *runs as a supervised
|
||||
process and serves the verbs locally to the host and on the bus*. A supervised process serving
|
||||
verbs is what this runtime is; whether that holder keeps a process of its own or serves through
|
||||
the runtime is for that record's build to say.
|
||||
- What got harder: one process carries every module's tool code on a node, so one module's
|
||||
faulty bundle can take down the node's tools. The runtime loads each bundle guarded and names
|
||||
the one that failed; the others serve.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| The runtime loads every bundle its memberships name and serves each tool on its subject | the runtime's tests against a real bus: two bundles, three tools, each answers |
|
||||
| A bundle that fails to load is named and the others serve | the same tests, with one bundle that throws on load |
|
||||
| The host supervises the runtime and restarts it | the host's tests over the launcher's shape |
|
||||
| A push that replaces a bundle reloads it without a restart | the runtime's tests: a bundle replaced on disk, the membership re-read, the new tool answers |
|
||||
| No module in the catalogue declares a container whose only purpose is tools | a catalogue check: a manifest with `tools` and an image artifact built on the tool runtime's base is refused once the runtime is live |
|
||||
| Live | `login-shell.execute@<node>` answers on every node from the node tools runtime; `docker ps` shows no per-module tool container |
|
||||
|
||||
## References
|
||||
|
||||
- [Research 018](../01-RESEARCH/018-the-operators-machine-as-modules/03-one-tool-executor-per-node.md)
|
||||
- [ADR 0150](0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md), [ADR 0047](0047-a-module-runs-its-code-as-its-own-process-with-its-own-account.md),
|
||||
[ADR 0152](0152-the-operators-surface-is-a-module-the-console.md), [ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md),
|
||||
[ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md), [ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md)
|
||||
- [To-be 33](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md), [to-be 34](../03-DESIGN/01-to-be/34-the-console.md)
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0132-a-seat-carries-the-tools-its-holder-must-serve.md
|
||||
---
|
||||
|
||||
# 176. The login shell is a node seat held by one shell module, and `execute` is its contract
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0040](0040-what-a-module-is.md) names the shell as its example of a *shared* seat: bash, zsh
|
||||
and fish all join `shell`, and one may be default. The operator's reading is sharper, and it
|
||||
matches [ADR 0126](0126-a-module-declares-its-own-seats.md) better: *installing* a shell is
|
||||
installing software, and several may be installed; *holding* the seat is being the login shell,
|
||||
which a node has exactly one of. A definition says which seats a module can hold; the assignment
|
||||
says which it does.
|
||||
|
||||
A seat carries the tools its holder must serve ([ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md)),
|
||||
and [to-be 33](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md) leaves which verbs each
|
||||
seat serves as a decision per seat, taken slowly. This is the first seat of the operator's
|
||||
environment, and the one every node has.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **A shared `shell` seat with a default**, as 0040's example reads. Rejected: *default* is a
|
||||
second concept beside *holder* for the same fact, and the `user` shape already makes the
|
||||
login shell declared state ([to-be 05](../03-DESIGN/01-to-be/05-the-node-host.md)).
|
||||
2. **No seat; each shell module sets the login shell for itself.** Rejected: two assigned shell
|
||||
modules would fight over `chsh`, and nothing would say which won.
|
||||
3. **An exclusive node-scoped seat, `login-shell`, declared by the shell modules, held by one
|
||||
per node.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. `login-shell` is a node-scoped seat declared by the shell modules.** zsh, fish and bash each
|
||||
declare that they can hold it; a node's assignment says which does; the controller refuses a
|
||||
second holder by name as for every seat. A shell module that is assigned without holding the seat
|
||||
is installed and nothing more.
|
||||
|
||||
**2. Holding the seat sets the account's login shell.** The holder's declaration carries the
|
||||
`user` shape with the shell it provides, so the login shell is declared state the host applies and
|
||||
gives back when the holding moves — `chsh` stops being a hook.
|
||||
|
||||
**3. The seat's contract is `execute`.** One verb, one argument, the command, run on the node the
|
||||
seat is scoped to as the operator account, answering with what it printed and how it exited.
|
||||
Every holder serves it; a holder may serve its own tools beside it
|
||||
([ADR 0170](0170-the-firewall-seat-serves-its-verbs.md) §2) — show the rendered configuration, list
|
||||
the plugins, set a prompt value.
|
||||
|
||||
**4. Any node may call it on any node.** The grant is the node tools runtime's
|
||||
([ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md) §5):
|
||||
*run `uptime` on every node* is five calls to one verb.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The first environment module is a shell: a package, files under the home owned by the account,
|
||||
a seat declaration and claim, a `user` shape, and one tool. It proves the whole pattern on every
|
||||
node, servers included, before anything graphical is written.
|
||||
- ADR 0040's shell example is read as *installed is not holding*; a dated note in that record says
|
||||
so. Its decision is untouched.
|
||||
- `execute` is a shell on every machine, addressed over the bus. That is the point, and it is
|
||||
the widest verb the mesh serves; it exists because the operator decided every node may call
|
||||
every tool, and this record does not narrow that.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| Two shell modules assigned to one node, one holding: one `user` shape in the declaration, naming the holder's shell | the controller's composition tests |
|
||||
| A second claimant is refused by name | the catalogue's seat tests |
|
||||
| `execute` runs as the account and answers output and exit status | the module's tool tests over a fake runner, and live on every node |
|
||||
| The seat's verb appears with its scope and machine in the node tools listing | the runtime's tests (to-be 33 §4) |
|
||||
|
||||
## References
|
||||
|
||||
- [Research 018](../01-RESEARCH/018-the-operators-machine-as-modules/04-the-seats-of-the-environment.md)
|
||||
- [ADR 0040](0040-what-a-module-is.md), [ADR 0126](0126-a-module-declares-its-own-seats.md),
|
||||
[ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md), [ADR 0170](0170-the-firewall-seat-serves-its-verbs.md)
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md
|
||||
---
|
||||
|
||||
# 177. A unit may be user-scoped, and the service manager is a node seat whose holder answers for the units
|
||||
|
||||
## Context
|
||||
|
||||
The host's `service` shape puts a system unit into a state. It has no user scope.
|
||||
[To-be 29](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) states the gap: *a
|
||||
workstation's per-user daemons have no form the mesh can send.* Four of the predecessor's
|
||||
environment modules ship user units — the desktop's reload watcher and bar watchdog, the audio
|
||||
module's masks, the power module's memory guard, the thermal daemon's profile switcher — and the
|
||||
predecessor needed a hook to enable them because *shipping a unit file does not run it*; one unit
|
||||
was deployed for months and ran on one machine only.
|
||||
|
||||
[ADR 0040](0040-what-a-module-is.md) says the host hardcodes no supervisor, and a swappable
|
||||
machine mechanism is a module implementing a capability — which is what the nftables module is for
|
||||
the packet filter ([ADR 0170](0170-the-firewall-seat-serves-its-verbs.md)). The service manager is
|
||||
reported today as a capability, `service-manager`, and held by nobody. The operator's proposal: a
|
||||
systemd module that holds the seat and serves the tools about units, system and user.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep user units as a module concern** — each module runs `systemctl --user` in a hook.
|
||||
Rejected: that is the hook that silently never ran, and an action over the link is refused.
|
||||
2. **The service-manager module applies units** on behalf of others, as a provision. Rejected by
|
||||
the operator: provisioning is for resources a provider creates for a consumer; a unit is
|
||||
declared state the host applies, as every resource is.
|
||||
3. **The host's `service` shape gains a user scope; a systemd module holds the service-manager
|
||||
seat and serves the verbs about units.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. The `service` shape gains `scope`: `system` (the default) or `user`.** A user-scoped unit
|
||||
is applied as the operator account through the account's own service manager: enabled, started,
|
||||
stopped, reloaded on its triggers, exactly as a system unit is, and refused on a node with no
|
||||
account, naming the fact. The host applies it; no module does.
|
||||
|
||||
**2. `node-service-manager` is a seat of the mesh's own, node-scoped**, seeded by the controller
|
||||
under this record, as ADR 0121 requires of a `node-*` name. The `systemd` module claims it and is
|
||||
assigned to every machine whose profile reports `service-manager`.
|
||||
|
||||
**3. The seat's verbs answer for every unit on the machine**, each taking an optional `scope`:
|
||||
`units`, `status`, `start`, `stop`, `restart`, `enable`, `disable`, `journal`. The host applies what
|
||||
is declared; the holder answers questions and operator acts about it, and says, for a mesh-held
|
||||
unit, that the host will restore what its declaration says.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The host's vocabulary grows by one field on one shape, asserted by its count test
|
||||
([to-be 05](../03-DESIGN/01-to-be/05-the-node-host.md)); an older host refuses a declaration
|
||||
carrying it, so the host rolls before the first module that uses it.
|
||||
- The predecessor's four user-unit modules become declarable without a hook.
|
||||
- The seat's holder is the first system seat held by a module that runs nothing of its own: its
|
||||
verbs are served by the node tools runtime ([ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md)).
|
||||
- What got harder: `journal` and `status` on a user unit need the account's manager reachable
|
||||
from the runtime's process, which runs as the node's account; the holder's tool escalates or
|
||||
switches user as it needs, which is ADR 0175 §4 applied.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A `service` with `scope: user` is enabled and started under the account, and refused with no account | the host's tests with a fake service manager |
|
||||
| The seat declares its verbs; a claim serving fewer is refused by name | the catalogue's seat tests |
|
||||
| The verbs act on a named unit in the named scope and name the unit's holder when the mesh declares it | the module's tests over a fake runner |
|
||||
| Live | the desktop's reload watcher declared `scope: user` on a workstation; `node-service-manager.status@<node>` reports it active |
|
||||
|
||||
## References
|
||||
|
||||
- [Research 018](../01-RESEARCH/018-the-operators-machine-as-modules/04-the-seats-of-the-environment.md)
|
||||
- [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md), [ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md),
|
||||
[ADR 0040](0040-what-a-module-is.md), [ADR 0170](0170-the-firewall-seat-serves-its-verbs.md)
|
||||
- [To-be 05](../03-DESIGN/01-to-be/05-the-node-host.md), [to-be 29](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md)
|
||||
+132
@@ -0,0 +1,132 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0170-the-firewall-seat-serves-its-verbs.md
|
||||
---
|
||||
|
||||
# 179. The intrusion seat serves its verbs, a container may log to the journal, and every door declares its jail
|
||||
|
||||
## Context
|
||||
|
||||
Read on the control node on 2026-10-02, the day the machines were confirmed filtered by the mesh
|
||||
alone ([ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md)): the intrusion
|
||||
prevention watched one door. Its two jails read the ssh daemon's journal and its own log, banned
|
||||
five failures in ten minutes for ten minutes, and in a day had seen twelve thousand failed logins
|
||||
from three hundred addresses and banned none of the busiest, which paced themselves at one try every
|
||||
ten minutes. The mail submission port took a hundred and sixty password guesses in the same day from
|
||||
thirty-eight addresses with no jail reading it at all; the forge and the public proxy had no jail
|
||||
either, and the proxy logged nothing a jail could read. Nobody could see the jails without a shell:
|
||||
the module's three tools existed in code and were served by nothing, and the seat it holds declared
|
||||
no verbs.
|
||||
|
||||
Three things were missing and they are three shapes the mesh already has. The packet filter's seat
|
||||
serves verbs every holder owes ([ADR 0170](0170-the-firewall-seat-serves-its-verbs.md)); the
|
||||
intrusion seat serves none. A module's `listens` compose into the machine's filter, and [to-be 31](../03-DESIGN/01-to-be/31-a-module-declares-its-fail2ban-jail.md)
|
||||
says a module's `jails` compose into the machine's intrusion prevention the same way — the controller
|
||||
composes them, and no module declares one. And a jail reads a log; a container's output goes to a
|
||||
file of the runtime's own under a path that changes when the container is recreated, which is why
|
||||
no jail could read the mail front end, the forge or the proxy, however they logged.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. The `node-intrusion-prevention` seat serves four verbs**, and a module that claims it serves
|
||||
all four or is refused the claim, as with every seat:
|
||||
|
||||
- `status` — every jail with what it watches, how many addresses it is counting failures against and
|
||||
holding now, and the totals since it started; one jail's detail when named. Read-only.
|
||||
- `banned` — every address banned now, with the jail holding it, when it was banned and when the ban
|
||||
ends. Read-only.
|
||||
- `ban` — ban one address in one jail now, for that jail's ban time. An operator's act on the live
|
||||
ban list, which the mesh composes the rules for and never writes itself.
|
||||
- `unban` — let one address go, from one jail or from every jail.
|
||||
|
||||
A holder may serve its own tools beside these; the fail2ban module reads one jail's effective
|
||||
settings as its own.
|
||||
|
||||
**2. A container may log to the journal.** `logging: journald` on a container has the host run it
|
||||
with the journal as its log driver; the journal keeps the container's name on every line, and
|
||||
`docker logs` keeps working. Where a container logs is part of its spec, so moving it recreates the
|
||||
container, and the only place besides the runtime's own file is the journal: a machine's intrusion
|
||||
prevention reads the journal already, for the ssh daemon, and a container that logs there is read
|
||||
the same way, by the container's name, whatever the container is called by the runtime this time.
|
||||
|
||||
**3. A module with a door declares its jail, and the holder composes them.** What to-be 31 designed
|
||||
is now the rule: a module whose service authenticates from outside — the mail front end, the forge,
|
||||
the public proxy — declares in its manifest what a failed attempt looks like in its log and how to
|
||||
ban on it, naming no node and no path; the module that holds the intrusion seat declares where the
|
||||
composed jails and filters land, and the mesh writes them on every machine that runs both. A machine
|
||||
not running the module has no such jail. The holder restarts its daemon on the composed file.
|
||||
|
||||
**4. The base is strict, and the mesh's own range is never banned.** Three failures in a day ban for
|
||||
a day, on every jail unless the jail says otherwise; banned twice in two weeks, by any jail, is
|
||||
banned for four. The attackers this mesh sees pace themselves under any ten-minute window; a day's
|
||||
window counts them. A person who mistypes three times from one address is out for a day from that
|
||||
address, and never from a machine of the mesh, whose range stays in the never-banned list the module
|
||||
has carried since [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md). The operator
|
||||
chose this knowing it.
|
||||
|
||||
**5. The proxy says a refused name in its log.** A request for a name this mesh does not serve, from
|
||||
outside, is what a scanner does; the proxy already logged a certificate refused for such a name, and
|
||||
now logs the plain request too, with the asking address last, as its own jail's filter expects it.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The seat's row gains four verbs; a mesh that already runs widens its row at the next controller
|
||||
start. The fail2ban module claims them and gains a runtime — a tool server whose image carries the
|
||||
fail2ban client, with the daemon's socket shared in from the machine, and nothing else of the
|
||||
machine. The daemon stays the machine's; what runs in the container is only the client.
|
||||
- **That runtime is the shape the catalogue has today, and it is on its way out.**
|
||||
[ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md),
|
||||
accepted the same day as this record, replaces a tool container per module with one tool runtime
|
||||
per node on the host side, taking each module's tools as a bundle. Nothing here depends on the
|
||||
container: the verbs, the client that speaks to the daemon over its socket, and the jails are the
|
||||
same code under either. This module converts with the packet filter's, whose runtime that record
|
||||
names, and the socket it needs becomes the node runtime's to reach rather than a mount of its own.
|
||||
- The host's container vocabulary grows by `logging`; an older host refuses a declaration that carries
|
||||
it, so the host rolls before the modules. Three containers are recreated once, when their modules
|
||||
are pushed with the field: the mail front end, the forge and the proxy — each a moment's outage.
|
||||
- The fail2ban module declares where jails compose (`jailing`) and the directory the filters go in;
|
||||
the mail, forge and proxy modules each declare one jail reading the journal by their container's
|
||||
name. The composed jail file is the one resource the daemon restarts on when a module arrives or
|
||||
leaves a machine.
|
||||
- The two base jails and the composed ones take the day's window; the ssh jail's ten minutes are
|
||||
gone. An address banned on the first day of this record stays banned for the day.
|
||||
- The module's three old tools, served by nothing, are replaced by the seat's four verbs and one
|
||||
own tool; `fail2ban_status` as a name is gone.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| The seat declares the four verbs; a claim that serves fewer is refused by name | the catalogue's seat tests |
|
||||
| `status`, `banned`, `ban` and `unban` read and steer the daemon through its client, with the shapes fail2ban 1.1.0 printed live; a non-address and a non-name are refused before anything runs | the module's tests over a fake command runner |
|
||||
| A container's `logging` reaches the runtime's arguments and its spec; a place other than the journal is refused | host tests |
|
||||
| A module's jails compose into the holder's file and a filter per jail, and the file is written empty when none is declared | the controller's composition tests (to-be 31) |
|
||||
| The proxy logs a refused name with the address last | the proxy's tests |
|
||||
| A jail's pattern names `<HOST>` once per shape, since two is a duplicate capture group and costs the machine every ban | the catalogue's manifest tests |
|
||||
| Live | done 2026-10-02: `status` and `banned` answered on both servers through the console; the proxy's jail counted seven refusals on the home server; a documentation address banned in the ssh jail came back with its end time and was released |
|
||||
|
||||
## Built and proven live, 2026-10-02
|
||||
|
||||
All five rules are in the mesh. The host carries `logging`; the controller's seat row carries the four
|
||||
verbs and the proxy says a refused name in its log; the fail2ban module holds the seat from a runtime
|
||||
with the daemon's socket shared in, composes the jails, and the mail front end, the forge and the
|
||||
proxy each declare one. Through the console on the control node: `status` listed five jails with what
|
||||
each watches, `banned` listed the nine the long jail holds, and a documentation address banned in the
|
||||
ssh jail came back with its ban's end time and was released again. On the home server the proxy's jail
|
||||
had counted seven refusals within minutes of starting.
|
||||
|
||||
**One fault, found by the machine and not by a test.** The proxy's pattern matched two shapes of
|
||||
refusal in one expression and so named `<HOST>` twice. fail2ban expands that placeholder into a named
|
||||
capture group; two of them is a duplicate group name, and the daemon refuses *its whole configuration*
|
||||
and exits — both servers kept no bans at all for about ten minutes, every jail and not the one at
|
||||
fault. The pattern is now one per shape. A manifest check refuses the mistake at merge time, naming
|
||||
what it would cost, which is the only reason this record can claim the rule rather than the instance.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0170](0170-the-firewall-seat-serves-its-verbs.md), [ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md), [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md), [ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md), [ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md)
|
||||
- [Design 31 — A module declares its fail2ban jail](../03-DESIGN/01-to-be/31-a-module-declares-its-fail2ban-jail.md), [Design 33 — The tools the mesh answers](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md), [Design 08 — Connectivity](../03-DESIGN/01-to-be/08-connectivity.md)
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0168-a-converged-machine-is-filtered-by-the-mesh-alone.md
|
||||
---
|
||||
|
||||
# 180. The found front end is uninstalled once a machine is converged
|
||||
|
||||
> **Renumbered 2026-10-02.** Written and merged as 0175 while another record already held that number on main (one tool runtime per node, merged minutes earlier); `cycle.py` refused main. The branch that lands last renumbers: 0178 and 0179 are claimed by open changes, so this is 0180. Nothing cited it by number.
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md) retires the firewall a machine
|
||||
was found with by disabling it, never flushing it, and keeps its configuration on disk so that
|
||||
returning the node to adopted can enable it again. [ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md)
|
||||
made the host keep it retired and say so. Both machines of this mesh that had a front end have been
|
||||
converged for days; neither is going back. What remained of the front end on each — its package,
|
||||
its unit enabled for boot on one, its empty chains still wired into the kernel's hooks, a chain of
|
||||
its container integration still dropping traffic on the IPv6 path until the day before this record
|
||||
— was not a rollback path. It was software nobody runs, left where a reader finds it and asks
|
||||
whether the machine has two firewalls.
|
||||
|
||||
The operator asked on 2026-10-02 that it be disabled and uninstalled. Disabled it already was. For
|
||||
uninstalled, the host had no word: a package could be declared present and not absent.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A package may be declared absent.** `absent: true` on a package resource has the host remove
|
||||
the package when it is installed and leave alone a machine that never had it, through the machine's
|
||||
own package manager, dependencies untouched. A declaration that stops saying a package is absent
|
||||
installs nothing: there is nothing to undo.
|
||||
|
||||
**2. The module that holds the packet filter seat declares the front end it replaced absent**, after
|
||||
its own filter is loaded, so the mesh's table is in force before the front end's package goes. On a
|
||||
converged machine the front end is therefore gone, not merely off; on an adopted machine nothing of
|
||||
this runs, because the filter module is assigned by the flip and not before.
|
||||
|
||||
**3. Returning such a machine to adopted enables nothing.** A machine with no firewall needs no
|
||||
openings ([ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md)); the host records the
|
||||
front end as *removed*, says so once, and asks nothing of a command that is not there. What
|
||||
ADR 0100 kept on disk for a return is kept only as far as the package manager keeps a changed
|
||||
configuration file; the rollback path it described is given up on purpose.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The host's vocabulary grows by `absent` on a package; an older host refuses a declaration
|
||||
carrying it, so the host rolls before the module.
|
||||
- The nftables module's declaration gains one resource; on the two machines of this mesh that were
|
||||
found with ufw, the next push removes it.
|
||||
- `node show` reads *found firewall: ufw, removed* on those machines from then on.
|
||||
- ADR 0100's sentence about a return to adopted restoring the found firewall holds only while the
|
||||
front end is installed, which after this record it is not on a converged machine.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| An absent package is removed when present, left when not, and read back | host tests over a fake package manager |
|
||||
| An uninstalled front end is recorded as removed and nothing is asked of it | a host test with ufw missing on a converged apply |
|
||||
| Live | done 2026-10-02: both machines report ufw gone — `pacman -Q ufw` has no answer, `node show` says *removed*, `status` is well. The home server said *retired* for six hours after the package went, because this record's step runs only after a clean apply ([ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md)) and one dead tracker was failing its applies ([ADR 0187](0187-a-dead-tracker-is-not-the-machines-failure.md)) |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0100](0100-a-node-in-use-is-adopted-before-it-is-converged.md), [ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md), [ADR 0170](0170-the-firewall-seat-serves-its-verbs.md)
|
||||
- [Design 08 — Connectivity](../03-DESIGN/01-to-be/08-connectivity.md)
|
||||
+118
@@ -0,0 +1,118 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-09-27
|
||||
deciders: jochen
|
||||
reconstructed: true
|
||||
extends: 02-DECISIONS/0112-a-module-definition-names-no-node-mesh-or-path.md
|
||||
---
|
||||
|
||||
# 181. The operator account is a node fact, and a home is a placement root
|
||||
|
||||
*Reconstructed. The controller shipped this on 2026-09-27 and
|
||||
[to-be 29](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) recorded it as built without a
|
||||
decision behind it. This record states what was decided, from the code and the design, and adds the
|
||||
two rules the code left implicit — what an empty account means for a module, and that the account is
|
||||
stated rather than discovered. Written 2026-10-02.*
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md) took every host path out of a
|
||||
module definition and gave a module's *system* data a place: a directory the mesh resolves under the
|
||||
node's root, owned by the module. It said nothing about the other half of a filesystem — the files
|
||||
that belong under a person's home and are owned by that person. The predecessor wrote several of
|
||||
those: the ssh client configuration, the shell's configuration, an agent's instruction files. It knew
|
||||
whose home it was writing into because each of its node records carried a login name. The mesh took
|
||||
the machine facts over and dropped the human one.
|
||||
|
||||
The loss was found the ordinary way: `ssh <node>` logged into the home-server under the workstation's
|
||||
own login name, because nothing in the mesh said the home-server's account was a different one
|
||||
([to-be 29](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md),
|
||||
[issue 172](../04-ISSUES/172-the-ssh-client-block-matches-one-spelling-of-a-machine/00-report.md)).
|
||||
|
||||
What the controller does since 2026-09-27: a node record carries an operator account and, optionally,
|
||||
its home; the account and its home are machine facts a definition may name in a resource's path, owner
|
||||
and content; a roster file may say it lives under the home, and is then rendered per node, placed under
|
||||
that node's account's home, owned by the account, and left out on a node with no account. On
|
||||
2026-10-02 **all four nodes of the live mesh carry an empty account**: the fact exists and nobody has
|
||||
stated it, so no home-scoped resource can land anywhere yet.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **The definition names the login.** `owner: <name>` in the module. Rejected: it is the installation
|
||||
written into a definition, which ADR 0112 forbids and
|
||||
[ADR 0155](0155-a-definition-names-no-installation-and-how-that-is-checked.md) checks for, and it is
|
||||
wrong on the first machine whose login differs — which is exactly the machine that surfaced this.
|
||||
2. **The host discovers the account.** The first non-system user, or whoever ran the enrolment.
|
||||
Rejected: a guess. A shared machine has several people on it, a server may have none, and a host
|
||||
deciding whose files these are is a decision the mesh then cannot see, state or correct.
|
||||
3. **The account is a fact the operator states on the node record, and the home is derived from it
|
||||
unless stated.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**A node has an operator account: the login name of the person who works on it.** It is stated by the
|
||||
operator on the node record, the way a node's address or mode is held there, and it is empty for a
|
||||
machine nobody logs into. Empty is a real state, not a missing value. The mesh holds the fact because
|
||||
everything below derives from it, and because it is precisely the fact that was lost when the
|
||||
predecessor's records were not carried over.
|
||||
|
||||
**The account's home is derived unless stated.** The superuser's home for the superuser, the
|
||||
distribution's conventional per-user home otherwise; a node whose account lives elsewhere states its
|
||||
home. One place computes the default, so a fact and the record cannot disagree about it.
|
||||
|
||||
**A resource may be placed under the home, owned by the account.** This is ADR 0112's move one level
|
||||
over: as a module's system directory is resolved under the node's root, a file under a person's home is
|
||||
resolved against the account's home, and owned by the account rather than by root or a module's own
|
||||
account. A definition names the account and its home as machine facts, never as a path; a roster fact
|
||||
may say it is a home file and is then placed and owned the same way. The controller resolves both at
|
||||
composition, and the host chowns what it creates.
|
||||
|
||||
**A node with no account cannot carry a home-scoped resource, and says so.** A roster fact that lives
|
||||
under the home is left out of that node's declaration rather than written to nowhere. A resource naming
|
||||
the account fact on such a node is refused at composition, naming the fact the machine does not have.
|
||||
A module that writes a person's files is thereby unassignable to a machine with no person on it, which
|
||||
is the right refusal.
|
||||
|
||||
**One account per node is what this record decides.** Several people on one machine is left open, with
|
||||
the constraint that allowing it must not force the common case — one workstation, one person — to name
|
||||
anything.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The operator states the account before any home-scoped module lands.** Today none is stated, so the
|
||||
first assignment of such a module begins with four node records.
|
||||
- The roster carries each node's account, so a composed ssh configuration logs in as the right person
|
||||
on every machine — the gap that surfaced this, closed by the same fact.
|
||||
- A family of modules becomes writable: everything the predecessor placed under a home — ssh client,
|
||||
shell, the agent's instruction files — is now a module naming a fact rather than a path
|
||||
([to-be 29 §2](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md)).
|
||||
- **What got harder:** a definition cannot say "my user's home" without the mesh knowing who the user
|
||||
is, so a module of this family is refused on a freshly enrolled machine until a person is named on
|
||||
it. That is a prompt, not an obstacle.
|
||||
- **Not decided here:** several accounts per node; a service unit running as the account rather than
|
||||
as root or a module; a one-off step run as the account. Each is a record of its own.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A resource's path and owner resolve the account and its home | controller tests on machine-fact resolution: a file naming the account facts lands under the account's home, owned by the account |
|
||||
| The home is derived unless stated | a controller test: the superuser's home for the superuser, the conventional home otherwise, the stated home when one is stored |
|
||||
| A home roster fact is left out on a node with no account | a controller test on roster composition: the file is absent from that node's declaration and present on a node with an account |
|
||||
| A resource naming the account on a node with no account is refused by name | a controller test on machine-fact resolution: the refusal names `account` and lists the facts the machine does have |
|
||||
| No definition names a home path | ADR 0112's catalogue test on host paths, which a `/home` or `/root` literal fails |
|
||||
|
||||
## References
|
||||
|
||||
- [to-be 29](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) — the design this record
|
||||
gives a foundation to, and its "what has shipped" section
|
||||
- [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md) — the system-path placement
|
||||
this mirrors; [ADR 0155](0155-a-definition-names-no-installation-and-how-that-is-checked.md) — why
|
||||
a login name may not be in a definition
|
||||
- [ADR 0120](0120-a-roster-fact-carries-its-format-as-a-template.md) — the roster fact a home file
|
||||
may be
|
||||
- [ADR 0182](0182-inside-a-home-the-mesh-owns-what-it-places-and-holds-the-rest-as-found.md) — what
|
||||
the mesh may and may not do inside the home this record lets it reach
|
||||
- mesh-controller `internal/inventory/nodes.go` (the account and its home on the node record),
|
||||
`internal/catalogue/machine_into_files.go` and `roster.go` (resolution and the home fact)
|
||||
+117
@@ -0,0 +1,117 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0118-undeclaring-gives-a-unit-back-the-state-it-was-found-in.md
|
||||
---
|
||||
|
||||
# 182. Inside a home, the mesh owns the directory and the files it places, writes into the tool's own files, and holds everything else as found
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0181](0181-the-operator-account-is-a-node-fact-and-a-home-is-a-placement-root.md) lets a module
|
||||
place files under a person's home. A home is unlike any directory the mesh has written into so far:
|
||||
it is shared with the person, and with every program the person runs. The agent's configuration
|
||||
directory on the laptop makes the point. On 2026-10-02 it holds thirty entries. The predecessor placed
|
||||
five of them (an instruction file, a conventions rule, a settings file it merged into, two skills); a
|
||||
sibling module placed a sixth (the node's identity rule). The agent itself writes the other
|
||||
twenty-four: its settings, its credentials, its history, the memory of every project it has worked in,
|
||||
its plugins, its session logs. Several of those are what [to-be 15](../03-DESIGN/01-to-be/15-the-agent-session.md)
|
||||
calls memory *written by the session itself and declared by nobody*: a mechanism that regenerated the
|
||||
directory would erase a season of it, silently, while reporting success.
|
||||
|
||||
The predecessor's own module recorded the hazard in the other direction. Its settings file was first
|
||||
shipped as *replace*, and every `/model` choice a person made inside a session was reverted to the
|
||||
template's value on the next synchronisation — on every node, indefinitely, with no indication why. It
|
||||
was changed to *merge*, and the comment explaining why is still in its manifest.
|
||||
|
||||
**And the generator is gone while its output stayed.** The predecessor was retired from the laptop on
|
||||
2026-10-01. Its six files are still on both workstations, with their content telling every session to
|
||||
use tools that no longer exist. Nothing owns them; nothing will ever rewrite or remove them.
|
||||
|
||||
[To-be 29 §3](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) drew the line for one directory,
|
||||
`~/.ssh`: the mesh owns the directory and the files it places; it holds the person's private keys and
|
||||
personal drop-ins as found. That was argued from the lockout `~/.ssh` can cause. The argument here is
|
||||
the same shape with a different stake — the person's work rather than the person's way in — and it has
|
||||
to hold for every directory the family of home-scoped modules will touch, so it is a rule, not a
|
||||
section.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **The module owns the directory whole**, regenerating it from the definition. Rejected: it destroys
|
||||
the memory, history and local settings the agent writes for itself, which is the failure to-be 15
|
||||
names and the predecessor's settings file demonstrated at small scale.
|
||||
2. **The module owns only the files it names, and nothing about the directory.** Rejected: *owning one
|
||||
file beside foreign ones is not owning anything* (to-be 29). The directory must exist, with the right
|
||||
owner and mode, before the tool first runs on a fresh machine; and a credentials file in a
|
||||
world-readable directory is a credentials file in the wrong directory.
|
||||
3. **The module owns the directory and the files it places; a file the tool writes for itself is
|
||||
written into, never over; everything else is held as found.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**A home-scoped module owns the directory it declares: its existence, owner and mode.** The host creates
|
||||
it if absent, owned by the account, and never removes it while it holds anything
|
||||
([ADR 0030](0030-data-outlives-the-mesh-that-declared-it.md)). Inside it, every path the module touches
|
||||
is in exactly one of four classes, and **the class is visible in the definition from the shape
|
||||
declared**, not inferred from what happened to be on disk:
|
||||
|
||||
| class | declared as | the host's rule |
|
||||
|---|---|---|
|
||||
| **owned** | a file with content, or a roster fact | written whole, regenerated, removed when undeclared; a file found there with no record of the mesh making it is kept once before it is written over ([ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md)) |
|
||||
| **written into** | a file written *into* a structured document | only the keys the definition names are set, every other key is kept, and each set key is given back when undeclared (ADR 0102). The key list is the module's and is short |
|
||||
| **written by the module's own process** | nothing the host applies: the module's code writes it from what it was handed | the file's content is never a declared file's content, because a declaration travels in the clear on the bus and the host records it; the module's code writes it, owned by the account, atomically. [ADR 0183](0183-the-anthropic-licence-manager-is-a-module-and-hands-tokens-to-the-agent-over-the-bus.md) says how for a credential |
|
||||
| **found** | nothing | never read, never rewritten, never removed. The person's memory, history, projects, local settings, their own rules and skills |
|
||||
|
||||
**A file the tool writes for itself is written into, never over.** The agent's settings file and its
|
||||
own state file are the tool's; the mesh has one or two facts to state in each. Setting those keys and
|
||||
nothing else is what lets a person's `/model` choice survive a push, and what lets the mesh's keys be
|
||||
taken back cleanly when the module goes.
|
||||
|
||||
**A predecessor's output is found.** A file placed by a generator that no longer exists is, to the
|
||||
mesh, a file it has no record of making. Where the successor module keeps the path, declaring it
|
||||
*adopts* it: the host keeps the original once and writes the mesh's. Where the successor does not keep
|
||||
the path, the mesh does not remove the file, because it removes nothing it did not make; **the operator
|
||||
removes it, once**, and the module's definition names those paths in its own documentation so the step
|
||||
is not forgotten. This is the first instance of the one-off setup step to-be 29 leaves open, and the
|
||||
rule chosen for it is that it is a person's act, listed, not a module's.
|
||||
|
||||
**The rule is the family's.** An ssh client module, a shell module, an agent module each declare their
|
||||
directory and classify their paths this way. A module that cannot say which class a path is in has not
|
||||
finished its definition.
|
||||
|
||||
## Consequences
|
||||
|
||||
- A person's work under their home survives every push and every unassign. The mesh's own files come
|
||||
and go with the module; the mesh's keys in the tool's files come and go with it; the directory stays.
|
||||
- **Stale files survive too.** Two workstations keep three predecessor files each until a person removes
|
||||
them — a visible cost, accepted over a mesh that deletes under a person's home. A module author who
|
||||
renames one of the mesh's own files has the ordinary path: the old resource id is undeclared and the
|
||||
host removes what it made ([ADR 0118](0118-undeclaring-gives-a-unit-back-the-state-it-was-found-in.md)).
|
||||
- A module's definition is longer by a classification, and a reviewer has one more question per path.
|
||||
That is the point: *which parts are managed must be explicit rather than inferred* (to-be 15).
|
||||
- **What got harder:** a module cannot seed a person's preference once and leave it. A seeded file
|
||||
([ADR 0087](0087-a-seeded-file-is-created-once.md)) is the shape for that, and it is available to
|
||||
this family unchanged; what is refused is a seed the module later wants to change, because what grew
|
||||
in it is the person's.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| The directory is created owned by the account and kept when the module goes | host tests of a directory resource with an owner (ADR 0051's and 0118's), and the family's lab check below |
|
||||
| An owned file found with no record is kept once, then written | host tests of ADR 0102's kept-original rule |
|
||||
| Only the declared keys of a written-into file change, and are given back | host tests of ADR 0102: declared keys set, the rest kept, restored when undeclared |
|
||||
| Nothing found is touched | the family's lab check: a machine with a seeded home holding a person's file beside a predecessor's; after apply the person's file is byte-identical, the predecessor's is kept as the original, the mesh's keys are set and the person's keys in the same file remain; after unassign the mesh's files are gone, the keys are restored, the person's files are untouched and the directory stands |
|
||||
| Every path a home-scoped module touches is classified | a catalogue review rule for this family: each path is a directory, a file, a file written into, a secret-and-step, or absent — the first module written to it is [to-be 36](../03-DESIGN/01-to-be/36-the-operators-agent-on-a-machine.md) |
|
||||
|
||||
## References
|
||||
|
||||
- [to-be 29 §3](../03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md) — the same boundary drawn for `~/.ssh`
|
||||
- [to-be 15](../03-DESIGN/01-to-be/15-the-agent-session.md) — a session's memory is declared by nobody
|
||||
- [ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md), [ADR 0087](0087-a-seeded-file-is-created-once.md),
|
||||
[ADR 0118](0118-undeclaring-gives-a-unit-back-the-state-it-was-found-in.md), [ADR 0030](0030-data-outlives-the-mesh-that-declared-it.md) — the mechanics each class rests on
|
||||
- [ADR 0051](0051-shared-data-is-the-operators.md) — the third case the host had no word for: what it neither made nor configured
|
||||
- the predecessor's `claude-code` module manifest, whose comment on `strategy: merge` records the reverted `/model` choice
|
||||
+163
@@ -0,0 +1,163 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0024-model-access-is-a-provision.md
|
||||
---
|
||||
|
||||
# 183. The Anthropic licence manager is a module holding a seat; it hands each node's agent its token over the bus, sealed; the controller and the host have no part
|
||||
|
||||
## Context
|
||||
|
||||
**The operator's stance, set on 2026-10-02 and sharpened during the day.** The controller has no part in
|
||||
the agent module. The host is module-agnostic: it knows no vendor, no agent, no path under a home. The
|
||||
agent module owns its own files. And there must be a *real* licence manager — a module that doles out
|
||||
the correct licence in every situation the mesh has: two subscription accounts and one API key today,
|
||||
used by a person's interactive agent on each workstation, by the mesh's own sessions, and by workers.
|
||||
|
||||
**What the predecessor built, read from its code the same day.** Two modules, split after an incident.
|
||||
A *manager* on exactly one node held every account's full OAuth grant encrypted, rotated each grant
|
||||
under a per-licence lease on a cadence and an expiry floor, published each rotation over its bus with
|
||||
the tokens encrypted, collected the vendor's usage figures per licence, and alerted once a day on
|
||||
repeated failure or on a refresh token within three days of its own expiry. A *consumer* on every node
|
||||
was the single writer of the agent's credentials file: it applied a published rotation, stripped the
|
||||
refresh token so a node could never rotate, pulled when stale, refused a stale grant by comparing
|
||||
expiries within one lineage, and mirrored a local login back to the manager only after checking the
|
||||
account's identity against the licence's record — because an unchecked mirror had once written one
|
||||
account's grant into another's row and published it mesh-wide. Three **touchpoints** with fallbacks: the
|
||||
node's interactive agent; the mesh's own sessions on the node, falling back to the node's licence; a
|
||||
worker's own account, falling back to the node's, and refusing to spawn when assigned a licence that
|
||||
could not be served. The split exists because four nodes refreshing one grant destroyed it: an OAuth
|
||||
refresh rotates the refresh token, and the predecessor's own code records both that a reused token
|
||||
killed a licence and that a malformed client id was once misdiagnosed as the same fault. **Whether a
|
||||
refresh token is single-use is not documented by the vendor**; the predecessor treated it as so, and
|
||||
this record keeps one rotation source for that reason while leaving the fact to be measured.
|
||||
|
||||
**What the mesh has.** [ADR 0050](0050-model-access-is-vendor-agnostic.md) put a per-vendor adapter
|
||||
inside the controller's licences context, with the carve-out that the manager node holds the refresh
|
||||
token readably; the catalogue has a manager and a consumer module built on it, assigned to nothing. The
|
||||
controller's licence commands are not seat verbs and cannot be asked for through the console
|
||||
([to-be 33](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md)). `model-access` is a vendor-blind
|
||||
provision ([ADR 0024](0024-model-access-is-a-provision.md)), and the operator's judgement is that the
|
||||
agent is not a vendor-blind consumer: it is coupled to an Anthropic subscription grant and nothing else,
|
||||
so a name that hides the vendor misdescribes the coupling
|
||||
([ADR 0027](0027-a-provision-names-what-the-consumer-is-coupled-to.md)).
|
||||
|
||||
**The bus's rule for a secret** ([to-be 32 §10](../03-DESIGN/01-to-be/32-what-a-module-declares.md)): the
|
||||
bus is not trusted with one; a secret travels sealed to its recipient, on core request/reply, never
|
||||
through a stream that persists it.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep the lifecycle in the controller** ([ADR 0050](0050-model-access-is-vendor-agnostic.md) as
|
||||
built), and make the agent module a consumer of `model-access` delivered by the host as a sealed
|
||||
file. Rejected by the operator: the controller and the host would both carry a part of an
|
||||
Anthropic-specific mechanism, and the agent's coupling is misnamed.
|
||||
2. **The manager delivers each short-lived token through the vault**, as a backend-issued secret the
|
||||
vault provides to each consumer ([ADR 0113](0113-the-vault-makes-every-secret.md)). Rejected: every
|
||||
hourly rotation becomes a vault delivery, a composition and a push to every node, and the host
|
||||
ends up writing a vendor's credential as a file — the module-agnostic host, carrying a vendor's
|
||||
traffic.
|
||||
3. **A seat-holding manager module that talks to the agent module on every node over the bus.**
|
||||
Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**The Anthropic licence manager is a module, `claude-licence-manager`, holding the mesh-scoped seat
|
||||
`anthropic-licence-manager`.** The seat's contract is the licence verbs: list the licences and their
|
||||
health, list the bindings, bind or switch a consumer, release one, refresh now, read usage, adopt a
|
||||
grant, register a node's key, answer a consumer's current token. One holder, on a node the operator
|
||||
assigns, is what makes rotation happen once ([ADR 0126](0126-a-module-declares-its-own-seats.md),
|
||||
[ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md)). The seat is named for the vendor,
|
||||
because what it manages is one vendor's grants and nothing else is coupled to it. The vendor-blind
|
||||
`model-access` provision stands for the consumers that do not care which vendor answers; the agent is
|
||||
not among them.
|
||||
|
||||
**The manager owns the licences.** The records, the grants, the bindings per touchpoint, the usage
|
||||
readings and the audit of every switch live in the manager's own store, not in the controller's
|
||||
licences context, which keeps only what it already serves to vendor-blind consumers. The manager is the
|
||||
one rotation source: it alone calls the vendor's token endpoint, under a lease per licence, on an expiry
|
||||
floor and a cadence it declares as a setting.
|
||||
|
||||
**The long-lived grants are encrypted at rest with a key the vault made for the manager.** The vault
|
||||
keeps custody of that one key as the manager's own secret ([ADR 0113](0113-the-vault-makes-every-secret.md));
|
||||
the grants themselves — a refresh token per subscription account, the API key — are the manager's
|
||||
rows, readable only by it. This is [ADR 0050](0050-model-access-is-vendor-agnostic.md)'s carve-out,
|
||||
moved with the manager: *one module, one node, the long-lived grants only.*
|
||||
|
||||
**The short-lived tokens travel module to module, sealed, on request/reply.** The agent module on each
|
||||
node makes a keypair of its own when it first runs — a private key made where it is used, never leaving
|
||||
([ADR 0113](0113-the-vault-makes-every-secret.md)) — and registers its public half with the seat. The
|
||||
manager hands a node its token by calling that node's agent module (`<module>.<tool>@<node>`,
|
||||
[ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md)) with the token
|
||||
sealed to that key, and the module answers *applied* or *refused* and why. An agent module that starts,
|
||||
or finds its token near expiry, asks the seat for its current token the same way. **A token is never
|
||||
published as an event**: what the manager emits — rotated, switched, failing, usage read — names the
|
||||
licence and nothing secret, and the audit logger records it. This is a second channel for a secret
|
||||
beside the vault's, and it is bounded as 0050's carve-out is: this vendor, tokens that live hours, sealed
|
||||
to one recipient, request/reply only.
|
||||
|
||||
**The agent module alone writes what the agent reads.** For a subscription licence it writes the
|
||||
agent's credentials file under the operator's home, as the operator, access-token-only, atomically. For
|
||||
the API-key licence it serves the key through the agent's own key-helper setting, so nothing is written
|
||||
under the home at all. For the mesh's own sessions and workers on that node, it is the local source of
|
||||
their token. **The host delivers the module's package and its state directory and knows nothing else**:
|
||||
no path under the home, no vendor, no file shape.
|
||||
|
||||
**A binding is explicit, and a switch is a reaction.** Every consumer — a node's interactive agent, the
|
||||
mesh's session on a node, a worker — is bound to a licence by the operator through the seat's verb, with
|
||||
the predecessor's fallbacks: a session inherits its node's licence, a worker inherits its node's, and a
|
||||
worker assigned a licence that cannot be served is refused rather than lent another. Exhaustion is
|
||||
observed and warned about once per crossing of a declared threshold; moving a consumer to another
|
||||
licence is a person's act through the seat's verb, as [ADR 0024](0024-model-access-is-a-provision.md)
|
||||
says, and the declaration language grows no conditional. An automated policy is not decided here.
|
||||
|
||||
**A login is attributed only to the account it belongs to.** When a person logs in on a node, the
|
||||
agent module reads the account's identity from the agent's own state and offers the grant to the
|
||||
manager sealed to the manager's key; the manager adopts it only when the identity matches the licence
|
||||
the node is bound to, and refuses with a notification otherwise.
|
||||
|
||||
## Consequences
|
||||
|
||||
- One module decides which licence every consumer gets, one module writes what each agent reads, and
|
||||
neither the controller nor the host carries a word of the vendor.
|
||||
- **A second sealed channel exists** beside the vault's, bounded as stated. A record that widens it to
|
||||
another vendor or a longer-lived secret is a new decision, not an application of this one.
|
||||
- The catalogue's `anthropic-manager` and `anthropic-consumer` modules, built on ADR 0050's placement,
|
||||
are retired once the manager runs; the controller's licences context stops holding Anthropic licences.
|
||||
- The console lists the seat's verbs, so a person switches a licence in a sentence, and the controller
|
||||
gains no `licence` verb.
|
||||
- **What got harder:** a manager that is down leaves every node on its last token until it expires;
|
||||
the agent module keeps the last token and says so. And a node whose agent module has not registered
|
||||
its key cannot be handed a token, which the manager reports by name.
|
||||
- Every interactive session on a machine shares the node's one agent directory, and so its licence;
|
||||
twenty sessions share it as one does. A consumer with a licence of its own on the same machine is a
|
||||
worker running from a home of its own with its own agent directory — the worker touchpoint above, for
|
||||
when workers exist ([ADR 0003](0003-agents-are-persistent-employees.md)); the predecessor ran its
|
||||
agents that way.
|
||||
- **Not decided here:** an automated switch on exhaustion; whether a refresh token is single-use, to be
|
||||
measured in the lab.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| Only the seat's holder calls the vendor's token endpoint | a catalogue test: no module but the manager names it; the manager's refresh runs under a lease per licence, tested with two concurrent runs |
|
||||
| A token crosses the bus only sealed, only on request/reply | a bus test: every message the manager publishes as an event carries no token; the hand-over is a request whose payload opens only with the receiving module's key |
|
||||
| The agent module's private key never leaves the node | the per-key test of ADR 0113, extended to this module's key |
|
||||
| The host writes nothing under a home and names no vendor | a catalogue test on the agent module's definition: no file resource under a home, no vendor word in anything the host applies |
|
||||
| A grant is attributed only to a matching identity | a manager test: a grant whose account identity differs from the bound licence's is refused and a notification emitted |
|
||||
| An unservable binding refuses rather than lends | a manager test: a worker bound to a dead licence is answered with a refusal, never another licence's token |
|
||||
| A switch through the console changes the token on the node and nothing in the answer is a token | a live check on one workstation |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0024](0024-model-access-is-a-provision.md), [ADR 0050](0050-model-access-is-vendor-agnostic.md) — the licence as a named thing, the carve-out this moves with the manager
|
||||
- [ADR 0027](0027-a-provision-names-what-the-consumer-is-coupled-to.md) — why the seat is named for the vendor
|
||||
- [ADR 0113](0113-the-vault-makes-every-secret.md) — the vault's custody of the manager's key, and the exception stated here
|
||||
- [ADR 0126](0126-a-module-declares-its-own-seats.md), [ADR 0132](0132-a-seat-carries-the-tools-its-holder-must-serve.md), [ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md) — a module's seat, its verbs, a call addressed to one machine
|
||||
- [to-be 32 §10](../03-DESIGN/01-to-be/32-what-a-module-declares.md) — a secret on the bus
|
||||
- [to-be 36](../03-DESIGN/01-to-be/36-the-operators-agent-on-a-machine.md), [to-be 39](../03-DESIGN/01-to-be/39-the-anthropic-licence-manager.md) — the two modules
|
||||
- the predecessor's `claude-licences` and `claude-code` modules, read 2026-10-02: the lease, the floor, the lineage comparison, the identity guard, the touchpoints
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0005-the-node-host.md
|
||||
---
|
||||
|
||||
# 184. A service the mesh asked to run is still running a moment later
|
||||
|
||||
## Context
|
||||
|
||||
The host already refuses to take a service manager's word for it. Three places in one function read
|
||||
a unit back after acting on it, each with a comment saying why: *a service manager accepting a
|
||||
command says the transaction was accepted, not that the unit is running — one that starts and
|
||||
immediately dies satisfies it.* The intent was right and the implementation did not reach it.
|
||||
|
||||
On 2026-10-02 the mesh composed a fail2ban jail whose pattern the daemon refused. The host wrote the
|
||||
files, restarted the service, read the unit back and reported *restarted*. The unit was `active` at
|
||||
that instant and `failed` 221 milliseconds later, which the unit's own record states. Both public
|
||||
machines then kept no bans at all — every jail, not the one at fault — and nothing in the mesh said
|
||||
so. The fault was found by calling a tool that needed the daemon, not by the mesh noticing.
|
||||
|
||||
The read-back races the failure. A service manager returns when it has started the process; a daemon
|
||||
that reads its configuration, refuses it and exits does so a fraction of a second afterwards. One
|
||||
look sees `activating` or `active` whatever the process is about to do, and *the host reports success
|
||||
for a machine that is already wrong* — the one shape of failure this host exists to refuse
|
||||
([ADR 0005](0005-the-node-host.md)).
|
||||
|
||||
A command the module declares — *test the configuration before restarting* — was considered and
|
||||
rejected. The link carries no actions ([ADR 0005](0005-the-node-host.md)), and a verification
|
||||
command is a command: a declaration that carried one would be remote execution over the bus,
|
||||
arriving as root on every machine, which is a far larger door than the fault it closes. The host
|
||||
does not need one. It already knows what it asked for.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A unit the host has just asked to run is read twice**, with a pause between the reads long
|
||||
enough for a daemon that refuses its configuration to have exited. Not running at the second look is
|
||||
a failure of that resource, named with the unit and the state it is in — the same failure the single
|
||||
read was always meant to catch.
|
||||
|
||||
**2. It is never a wait for a unit to come up.** A unit still starting reads as running at both
|
||||
looks and is accepted, exactly as before. What the second look catches is a unit that *was* running
|
||||
and is not any more. A service asked to be stopped is not waited on at all.
|
||||
|
||||
**3. The host tests nothing and runs nothing of a module's.** The second look is the host checking
|
||||
the state it was told to establish, which is its whole job; the declaration gains no vocabulary, and
|
||||
no command reaches a machine that did not already come from a built artifact.
|
||||
|
||||
## Consequences
|
||||
|
||||
- Every apply that starts, restarts or reloads a service spends a moment confirming it. The cost is
|
||||
bounded by the number of services that changed in that apply, which is usually none.
|
||||
- A module whose configuration the mesh composes — the packet filter, the intrusion prevention, the
|
||||
resolver — now fails its apply when the composition is bad, instead of reporting success onto a
|
||||
dead daemon. `status` names the machine, which is how the operator finds out.
|
||||
- It does not prevent the bad composition. [ADR 0179](0179-the-intrusion-seat-serves-its-verbs-and-every-door-declares-its-jail.md)'s
|
||||
manifest check is what refuses the one that caused this, at merge time; this record is what makes
|
||||
the *next* one visible within a minute rather than invisible until something asks the daemon a
|
||||
question.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A unit that is running at the first look and dead at the second fails the apply, naming the unit and its state | a host test over a service manager that answers as systemd does |
|
||||
| A unit still starting is accepted at both looks | a host test |
|
||||
| A service asked to be stopped is not waited on | a host test |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0005](0005-the-node-host.md), [ADR 0179](0179-the-intrusion-seat-serves-its-verbs-and-every-door-declares-its-jail.md)
|
||||
- [Design 05 — The node host](../03-DESIGN/01-to-be/05-the-node-host.md)
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0154-the-meshs-own-verbs-are-the-controller-seats-tools.md
|
||||
---
|
||||
|
||||
# 185. A control plane behind its seat's row serves what it can
|
||||
|
||||
## Context
|
||||
|
||||
The mesh's own verbs are the controller seat's tools, and the seat's row is the store's
|
||||
([ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md)). A control plane reads the
|
||||
row at start and installs a handler per verb; a verb the row carries that the binary cannot run was
|
||||
refused at start rather than at the first call, so that a disagreement between the row and the
|
||||
binary was said early. The refusal aborted the start.
|
||||
|
||||
On 2026-10-02 a merge added one verb. The new control plane started, widened the row, and ran. A
|
||||
push a few seconds later recreated its container at the previous image — a stale declaration from
|
||||
an overlapping wave, [issue 201](../04-ISSUES/201-a-push-recreated-the-controller-behind-the-row-its-successor-wrote/00-report.md) —
|
||||
and the older binary read a row naming a word it had never heard. It refused to start, and kept
|
||||
refusing. The mesh had no voice for ten minutes: no verb answered, no node could be pushed, no build
|
||||
was dispatched, and `status` said nothing because `status` is one of the verbs that had stopped
|
||||
being served. The way back was a person running the binary by hand outside its service, because the
|
||||
push that would have replaced it is itself a verb of the control plane that was down.
|
||||
|
||||
The check was right about the fact and wrong about the cost. A row ahead of a binary is the ordinary
|
||||
state of a roll-out: the row is widened by whichever control plane starts first, and a mesh with one
|
||||
control plane sees that gap on every merge that adds a verb. Making it fatal turned a transient into
|
||||
an outage with no path out that did not need a human.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A control plane serves the verbs it can run and does not refuse to start for the ones it
|
||||
cannot.** The row remains the authority on what the seat serves; this is only about what this binary
|
||||
does when it is behind the row.
|
||||
|
||||
**2. A verb it cannot run answers the reason.** Not silence and not a missing subject: a caller gets
|
||||
a sentence naming the verb, saying this control plane cannot run it and that it is a verb of a newer
|
||||
build. A verb that is simply absent from the row is still not served at all — that is the row
|
||||
deciding, which is unchanged.
|
||||
|
||||
**3. It says so once at start**, naming every verb of the row it cannot run, so the gap is visible
|
||||
in the log of the thing that has it rather than only at the moment somebody calls one.
|
||||
|
||||
**4. A mesh with no controller seat at all is still a refusal.** That is not a version gap, it is a
|
||||
mesh that has not been seeded, and nothing this control plane does would be meaningful.
|
||||
|
||||
## Consequences
|
||||
|
||||
- An overlapping roll-out costs the verbs the newer build added, for as long as the older binary is
|
||||
in place. Everything else — every push, every build, every read — keeps working, and the ordinary
|
||||
machinery that notices a machine is behind is what puts the newer binary back.
|
||||
- The log gains one line on a control plane that is behind, and nothing on one that is not.
|
||||
- Issue 201's other half remains: the push that sent a stale declaration is a race worth closing on
|
||||
its own terms. This record makes that race survivable rather than fatal, which is the difference
|
||||
between a transient and an outage, and is deliberately the cheaper half.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A row carrying a verb this build cannot run still serves every verb it can, and names the one it cannot | a controller test over a widened row |
|
||||
| The unknown verb answers a sentence naming itself and saying this build is behind | the same test |
|
||||
| A mesh with no controller seat is refused | the existing start-up path |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md), [ADR 0162](0162-a-merge-produces-a-tiered-plan-the-mesh-keeps.md)
|
||||
- [Issue 201](../04-ISSUES/201-a-push-recreated-the-controller-behind-the-row-its-successor-wrote/00-report.md)
|
||||
- [Design 33 — The tools the mesh answers](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md)
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0179-the-intrusion-seat-serves-its-verbs-and-every-door-declares-its-jail.md
|
||||
---
|
||||
|
||||
# 186. A ban list never holds a neighbour, and the mesh's own bans are its own wherever they hang
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0179](0179-the-intrusion-seat-serves-its-verbs-and-every-door-declares-its-jail.md) gave the
|
||||
public proxy a jail. Within the hour the home server's ban list held `192.168.1.1` — the house's own
|
||||
router. The router reflects local traffic, so every client in the building reaches that machine as
|
||||
the gateway's address; one local request for a name the mesh does not serve, three times in a day,
|
||||
and the whole house is refused by the machine it was asking. The jails inherited an `ignoreip` of
|
||||
the loopback and the mesh's own range, which was right when the only jail read the ssh daemon and
|
||||
the only clients were the mesh's; a jail on a public front door sees the neighbours too.
|
||||
|
||||
The same jail broke the other half of [ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md).
|
||||
The home server began reading *NOT the mesh alone: 1 rule set the mesh did not write refuses traffic
|
||||
here*, and the rule set named was the mesh's own ban chain, written by the mesh's own intrusion
|
||||
prevention minutes earlier. The host's reader of the legacy filter required every path into a chain
|
||||
of refusals to come from a built-in chain whose policy accepts, before it would call that chain a
|
||||
ban. On that machine the chain hangs off the container runtime's user chain as well as the input
|
||||
chain, and the runtime had set the forward policy to DROP — so the mesh reported its own work as a
|
||||
foreigner's, on the one machine where the group's exit condition was supposed to hold.
|
||||
|
||||
Both faults are one mistake in two places: a rule written about the public internet, applied to
|
||||
everything that arrives.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A ban list never holds a neighbour.** The jails the mesh composes never ban a source on a
|
||||
private range — the mesh's own range, which was already named rather than written
|
||||
([ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md)), and every address space
|
||||
reserved for private use beside it, in both families. A machine behind a router that reflects local
|
||||
traffic sees its whole building as one address; a ban there is a self-inflicted outage, and the
|
||||
sources worth banning are not on those ranges in the first place.
|
||||
|
||||
**2. The mesh's own bans are its own wherever they hang.** A chain of refusals is a ban list when
|
||||
every refusal names the sources it refuses and the chain accepts nothing — the rule the host already
|
||||
applied to the packet filter's own tables, now applied to the legacy filter too, and nothing more.
|
||||
The policy of the chains that jump into it says nothing about what it is: that policy is already
|
||||
classified where it belongs, as the container runtime's, and requiring it here counted it twice.
|
||||
|
||||
**3. A chain that accepts anything is still not a ban.** That is what keeps a predecessor's
|
||||
allow-these-and-drop-the-rest chain classified as something an operator must look at, which is the
|
||||
distinction [ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md) exists to draw.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The composed jails gain the private ranges in their never-ban list. An address already banned
|
||||
stays banned until it is released; the house's router was released by hand the moment it was found.
|
||||
- The home server reads *the mesh alone* again, which is group 7's exit condition and was false for
|
||||
about an hour.
|
||||
- A machine whose apply fails for an unrelated reason does not revisit its found firewall's record
|
||||
at all — the step runs only after a clean apply ([ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md)).
|
||||
The home server's record therefore still reads *retired by the mesh* although the front end is
|
||||
uninstalled, and will correct itself once that machine's own stuck module is fixed. It is a stale
|
||||
record, not a wrong machine.
|
||||
- The record number the front end's removal was given moved under it: another session took 0175
|
||||
while that record was in review, and it is now
|
||||
[ADR 0180](0180-the-found-front-end-is-uninstalled-once-a-machine-is-converged.md). The citations
|
||||
the host and the control plane print were pointing at an unrelated record and are corrected here.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A private source is never banned | the module's jail configuration, read back by `fail2ban.fail2ban_settings` on a machine |
|
||||
| The mesh's own ban chain reads as a ban behind a dropping forward policy | a host test over the home server's own captured rule set |
|
||||
| A chain that accepts anything is not a ban | a host test |
|
||||
| Live | done 2026-10-02: all four machines read *the mesh alone*, the home server counting its own ban chain as a ban; no ban held anywhere is a private address |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0179](0179-the-intrusion-seat-serves-its-verbs-and-every-door-declares-its-jail.md), [ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md), [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md), [ADR 0180](0180-the-found-front-end-is-uninstalled-once-a-machine-is-converged.md)
|
||||
- [Design 08 — Connectivity](../03-DESIGN/01-to-be/08-connectivity.md), [Design 31 — A module declares its fail2ban jail](../03-DESIGN/01-to-be/31-a-module-declares-its-fail2ban-jail.md)
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0136-a-step-gates-its-module-not-the-machine.md
|
||||
---
|
||||
|
||||
# 187. A dead tracker is not the machine's failure
|
||||
|
||||
## Context
|
||||
|
||||
The home server had not applied a declaration cleanly since midday. One run-once step — the one
|
||||
that writes a media app's download clients and indexers through the app's own API — exited
|
||||
non-zero, forty-nine times over six hours, for one public tracker that had stopped answering. The
|
||||
step's own words: the entry was *written*, and the app's test of it then failed with a 400 from the
|
||||
indexer proxy. The machine reported *not doing what it was told* for the rest of the day.
|
||||
|
||||
What that gated matters more than the step. A converged machine retires the firewall it was found
|
||||
with only after a clean apply ([ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md)),
|
||||
so that machine went on recording its found front end as merely *retired* long after the package
|
||||
had been uninstalled ([ADR 0180](0180-the-found-front-end-is-uninstalled-once-a-machine-is-converged.md)).
|
||||
A dead public tracker was holding a firewall record hostage, which is not a connection anybody
|
||||
would design.
|
||||
|
||||
The step already knew this was not its business. It had a rule for exactly this: an entry the mesh
|
||||
only *found and re-pointed*, rather than one it was told to make, whose feed is gone, is said and
|
||||
left as found — *failing the node's apply on every heartbeat for it reports the mesh as wrong about
|
||||
a tracker*. The rule was there and matched one shape of the fault. An app can refuse to save such an
|
||||
entry, and it can save it and then fail its own test; saving validates settings, and the test runs a
|
||||
live search. The rule caught the first and let the second through.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. An entry the mesh only found is never the machine's failure.** Whatever shape the app's
|
||||
refusal takes — it would not save it, or it saved it and its own test fails — an indexer the mesh
|
||||
found and re-pointed is reported as a notice and left as found. What decides is whose entry it is,
|
||||
not which sentence the app returned.
|
||||
|
||||
**2. What the mesh is answerable for is the plumbing.** That the entry exists, points at this
|
||||
mesh's indexer proxy, and carries the credential the mesh delivered — which was checked against the
|
||||
proxy before anything was written. Whether a public tracker answers today is not the mesh's to
|
||||
promise, and a machine that reports itself broken because one did is lying about itself.
|
||||
|
||||
**3. An entry the operator listed is theirs to insist on.** An indexer named in the step's settings
|
||||
is one the mesh was told to make, and it still fails the step when it cannot be made to work. The
|
||||
notice says so, and says that listing the indexer is how to turn it back into a failure.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The home server applies cleanly again, and everything a clean apply gates — its found firewall's
|
||||
record among it — follows.
|
||||
- A tracker that dies is a line in a report rather than a machine that reads as broken. An operator
|
||||
who wants it gone removes the entry or repairs the feed; the mesh says which, every time it runs.
|
||||
- The four Servarr modules carry one byte-identical copy of this step each
|
||||
([ADR 0069](0069-a-module-is-a-repository-and-a-path.md)), so the change lands in four places and
|
||||
a test refuses any drift between them.
|
||||
- It does not widen to a download client: one the mesh was told to write and cannot is still a
|
||||
failure, because the mesh chose it and nothing else will fix it.
|
||||
|
||||
## How this is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A found feed whose tracker answers an error after the entry was written is a notice | the step's tests, with the home server's own message and the app's two validations modelled apart |
|
||||
| An indexer the settings list is still a failure | the same test |
|
||||
| The four copies of the step do not drift | the step's own sameness test |
|
||||
| Live | done 2026-10-02: the home server applies cleanly after six hours of failing, `status` holds no machine wrong or behind, and its found firewall reads *removed* |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0136](0136-a-step-gates-its-module-not-the-machine.md), [ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md), [ADR 0180](0180-the-found-front-end-is-uninstalled-once-a-machine-is-converged.md), [ADR 0069](0069-a-module-is-a-repository-and-a-path.md)
|
||||
+131
@@ -0,0 +1,131 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md
|
||||
---
|
||||
|
||||
# 188. A module's own code is bundles in any language, and a tools bundle speaks MCP to the runtime
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md) put one
|
||||
tool runtime on every node and said a module brings its tools as a bundle. The runtime that exists
|
||||
is written in TypeScript and brings a bundle to life by **importing it into its own process**, which
|
||||
only JavaScript can be. The SDK ([ADR 0039](0039-what-the-sdk-holds-and-refuses.md)) is one
|
||||
TypeScript package. The builder knows three toolchains — TypeScript, Go, Python — and every one of
|
||||
the 35 catalogue modules with tools wraps them in a container on the runtime's TypeScript image.
|
||||
Nothing in the records says a module's code may be written in anything else, and nothing refuses a
|
||||
module that wraps its own code in an image to get around that.
|
||||
|
||||
The operator's direction, stated on 2026-10-02 and repeated: *the SDK is the most important part;
|
||||
we must not limit developers; tools can be written in any possible language — Rust, C, Go,
|
||||
JavaScript. A service in Go or Rust as a systemd unit must be possible too. One module can deliver
|
||||
all kinds of bundles: one for its tools, one for a seat's implementation, one for a daemon. Support
|
||||
the bare minimum first, as a skeleton; a full implementation comes when the work requires it.*
|
||||
|
||||
Measured against that: the `bundle` artifact kind already names a language and the `process`
|
||||
resource already runs a command from an unpacked bundle as a unit the host writes
|
||||
([ADR 0150](0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md)), so a Go
|
||||
daemon as a native service is possible today and one module in the catalogue does it. What is not
|
||||
possible is a tool in any language but one, and what is not written is that any of this is the
|
||||
rule.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **One SDK, one language, as now.** Rejected: it limits who can write a module to one
|
||||
ecosystem, which the operator declines, and it is what made every module's tools a container
|
||||
on one image.
|
||||
2. **A full bus client per language.** Each SDK speaks the bus itself; the runtime only
|
||||
supervises. Rejected: a transport in every SDK is what ADR 0039 refuses, and a bus change
|
||||
would then rebuild every module in every language — the cascade, multiplied.
|
||||
3. **A tools bundle is a process the runtime launches and speaks a small local protocol to,
|
||||
and that protocol is MCP over stdio.** Chosen. The runtime already speaks MCP outward (the
|
||||
console); speaking it inward to a child process is the same vocabulary. Every language that
|
||||
has an MCP server library can write a tools bundle today with no mesh SDK at all, and the
|
||||
mesh's own SDK for a language is a thin convenience over it. The transport stays in the
|
||||
runtime, so a bus change rebuilds nothing.
|
||||
4. **A protocol of the mesh's own design.** Rejected: a second way to describe a tool, its
|
||||
schema and its call, inventing what MCP already settled, for no gain.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A module's own code is bundles, in any language the mesh has a toolchain for, and never an
|
||||
image.** A `bundle` names its language and what it is for. Images are for third-party software a
|
||||
module installs — a database, a forge — never for code the module wrote. One module may declare
|
||||
several bundles: its tools, its implementation of a seat's verbs, a daemon, a step. Each is built
|
||||
alone and delivered alone, as [ADR 0156](0156-an-artifact-is-what-a-build-produces-and-the-store-is-named-for-its-scope.md)
|
||||
already has it.
|
||||
|
||||
**2. A bundle the runtime serves is a process that speaks MCP over stdio.** The node's runtime
|
||||
launches it as the bundle names it — an interpreter and a file, or a binary — with the runtime's
|
||||
environment, asks `tools/list`, and answers each call on the bus by `tools/call`. A tool whose name
|
||||
is `<seat>.<verb>` is the module's implementation of that seat's verb; any other name is the
|
||||
module's own tool. Everything the runtime does with what it is told — subjects from the membership,
|
||||
a held seat's verbs, the `tools` answer, a bundle that fails named and the others serving — stays as
|
||||
[ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md) and
|
||||
[ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md)
|
||||
have it. A TypeScript bundle may still be imported into the runtime's own process; that is a
|
||||
shortcut over the same contract, not a second contract, and a TypeScript bundle written against
|
||||
the protocol is served the same way as any other.
|
||||
|
||||
**3. A bundle that is a service is a `process`**, run by the host as a unit, in whatever language it
|
||||
is compiled from, exactly as the host's own bundle already is. Nothing new is decided here; it is
|
||||
said so that it is the rule and not an example.
|
||||
|
||||
**4. One thin SDK per language, and the test of ADR 0039 applies to each.** An SDK for a language
|
||||
holds the MCP-over-stdio loop, the tool-definition type and the few primitives a module's code
|
||||
needs; it holds no transport, no module's client and nothing volatile. Where a language has a
|
||||
sound MCP library, the SDK wraps it rather than re-implementing it. The languages are those that
|
||||
make sense to write a module in; the first set is TypeScript, Go, Python, Rust and C, and the set
|
||||
grows when a module needs one, not before.
|
||||
|
||||
**5. Skeleton first.** Each piece — a toolchain, a launcher, an SDK — exists at the bare minimum
|
||||
that lets one bundle in that language be built, delivered and answer one tool on the live mesh.
|
||||
Anything beyond that is added when a module needs it. A skeleton that is not proven by one bundle
|
||||
answering is not a skeleton; it is a promise.
|
||||
|
||||
> **The mechanism changed — 2026-10-03, by ADR 0193.** §2's allowance that a TypeScript bundle may
|
||||
> be imported into the runtime's own process is withdrawn: every served bundle is launched, and the
|
||||
> build makes each served entrypoint executable. The rest of §2 stands.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The runtime gains a launcher beside its loader. The loader, the memberships, the seats and the
|
||||
failure handling built for ADR 0175 stand; the launcher is the one new step.
|
||||
- The builder gains a toolchain per language, each at the skeleton: compile, pack, name the
|
||||
entrypoint. Rust and C are new; a language that compiles to a binary says its operating system
|
||||
as a Go bundle already does.
|
||||
- An existing MCP server in any language is already a valid tools bundle. What the mesh adds is
|
||||
the subjects, the seats and the memberships around it.
|
||||
- The gate [to-be 38](../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP2 adds —
|
||||
refusing a tools container built on the runtime's image — widens: a module whose own code is
|
||||
an image artifact is refused at registration, naming this record.
|
||||
- What got harder: a tools bundle is now a process per module on the node rather than code in
|
||||
one process, so the runtime supervises children and restarts one that dies. The one-process
|
||||
shape ADR 0175 counted on for the TypeScript shortcut remains available for it.
|
||||
- ADR 0039's "what the SDK holds" now reads per language; its refusals are unchanged and are the
|
||||
reason option 2 was rejected.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A module's own code is never an image | the catalogue's registration check: a manifest with a `bundle` kind of own code *and* an image artifact built from the module's own directory is refused, naming this record |
|
||||
| A tools bundle in a language other than TypeScript answers on the bus | the runtime's tests: a bundle written against the protocol in a second language, launched, its tool called over a real bus |
|
||||
| A TypeScript bundle written against the protocol is served like any other | the same tests, with the TypeScript shortcut off |
|
||||
| Each SDK is thin | each SDK's own README states what it holds under ADR 0039's test, and its size is in the mesh's records |
|
||||
| Live | a tool in a compiled language answers from the node's runtime on one machine |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md),
|
||||
[ADR 0039](0039-what-the-sdk-holds-and-refuses.md),
|
||||
[ADR 0150](0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md),
|
||||
[ADR 0156](0156-an-artifact-is-what-a-build-produces-and-the-store-is-named-for-its-scope.md),
|
||||
[ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md)
|
||||
- [To-be 38](../03-DESIGN/01-to-be/38-building-the-operators-machine.md) — the work packages this
|
||||
record widens
|
||||
- The Model Context Protocol's stdio transport — the local protocol a tools bundle speaks
|
||||
+117
@@ -0,0 +1,117 @@
|
||||
---
|
||||
topic: the mesh
|
||||
status: accepted
|
||||
date: 2026-10-02
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md
|
||||
---
|
||||
|
||||
# 190. A seat's work is shared by its holders, and building is the first such role
|
||||
|
||||
## Context
|
||||
|
||||
Work addressed to a role goes to the seat's `accept` subjects, on a per-seat work queue
|
||||
([design 25](../03-DESIGN/01-to-be/25-the-bus-on-nats.md) §1, [ADR 0041](0041-events-are-a-relationship.md)).
|
||||
The holder's worker on that queue is already a queue group — *"even though the seat guarantees one
|
||||
holder … the day somebody allows two holders for throughput, every message is processed twice with
|
||||
nothing reporting it"* — and design 25 already says what a build queue shared by several machines is:
|
||||
*a seat's `accept` subjects, on a work queue with a queue group of holders*. The mechanism was drawn.
|
||||
Two things stopped it being used.
|
||||
|
||||
First, the build role is a **mesh-scoped** seat, `mesh-build-machine`, so there is one holder in the
|
||||
whole mesh ([ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md):
|
||||
*the mesh's single build machine*). Second, the worker is a push consumer with **one delivery in
|
||||
flight** — set so after 2026-10-01, when a push consumer handing out many at once left twenty-six of
|
||||
forty-three asks undelivered ([issue 175](../04-ISSUES/175-an-announcement-behind-a-long-build-comes-back/00-report.md)) —
|
||||
and one in flight on a shared consumer is one build at a time across every holder there could be.
|
||||
|
||||
Measured on 2026-10-02: a change to code comments in the tool runtime rebuilt its thirty-five
|
||||
dependent images, one after another, on one machine, for about half an hour, while three other
|
||||
machines with a container runtime sat idle; the work the mesh wanted next waited behind it. The
|
||||
operator's words: *this is our first occurrence of a mesh advantage* — and: *make sure the setup is
|
||||
done generically, so if another module also requires mesh functionality it can re-use the pattern.*
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **A second build machine by configuration** — a concurrency setting on the one holder, or a second
|
||||
holder admitted by hand. Rejected: a setting on one machine shares nothing, and a second holder
|
||||
of a mesh-scoped seat contradicts what a mesh seat means.
|
||||
2. **A build-specific dispatcher** — the controller choosing a machine per build and asking it by
|
||||
name. Rejected: it reinvents the queue the bus already is, it makes the controller a scheduler,
|
||||
and it is specific to building; the next role needing the same would build its own.
|
||||
3. **A seat's work is shared by its holders, and the build role becomes node-scoped.** Chosen. It is
|
||||
what the bus was drawn to do, it is one rule for every role rather than one for building, and
|
||||
"the machines that are online and hold the seat" is exactly the set a queue group's members is.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. Work asked of a seat is taken by whichever of its holders is idle.** Every holder of a seat with
|
||||
`accepts` reads the seat's one work queue; a node-scoped seat held on several machines has several
|
||||
holders, and an ask goes to one of them. The asker addresses the role — `mesh.seat.<seat>.accept.<verb>`
|
||||
— and never a machine. The outcome, the role's own event, says which machine did the work (`on`), as a
|
||||
build's already does ([ADR 0157](0157-a-build-says-what-it-does-on-the-bus-as-it-happens.md)).
|
||||
|
||||
**2. A holder takes one ask at a time, when it is idle, by pulling.** The worker is a pull consumer:
|
||||
a holder fetches one ask, works it, acknowledges, fetches the next. The server never hands an ask
|
||||
to a busy holder, so a slow machine never holds work an idle one could take — the fault issue 175
|
||||
found in push delivery is removed by the shape rather than by a limit, and the one-in-flight limit
|
||||
that made the shared queue serial goes with it. A holder that dies mid-work leaves its ask to be
|
||||
redelivered to another, as today.
|
||||
|
||||
**3. Work that must run on one particular machine is not a work queue.** That is a node seat's verb
|
||||
asked of that machine ([design 33](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md) §4), and
|
||||
nothing here changes it. A role's work queue is for work whose result is the same whichever holder
|
||||
does it: a build is, because what comes out is published by digest to the mesh's store.
|
||||
|
||||
**4. This is one pattern, not one role's.** Any module that declares a node-scoped seat with
|
||||
`accepts` gets decisions 1 and 2 with no further mechanism: the controller derives the queue and the
|
||||
worker, the holders pull, the module's manifest says what every holding machine must have. The
|
||||
build agent is the first; a module needing work done *somewhere on the mesh* — a scan, a
|
||||
conversion, a fetch — declares a seat of its own the same way
|
||||
([ADR 0126](0126-a-module-declares-its-own-seats.md)).
|
||||
|
||||
**5. Building is the first such role.** The build role is `node-build-agent`, scope node, with the
|
||||
same `build` ask and the same `started`, `built` and `log.<id>` events as before. Its holder is the
|
||||
`build-agent` module: the builder as it is — a container runtime, the artifact store and the package
|
||||
registry resolved as provisions, a workspace, the bus credential — assignable to every machine that
|
||||
has a container runtime. `mesh-build-machine` and the `builder` module are retired when the new
|
||||
holder is assigned where the old one was. The tiered plan ([ADR 0162](0162-a-merge-produces-a-tiered-plan-the-mesh-keeps.md))
|
||||
is unchanged: a tier's asks go out together and are now worked together.
|
||||
|
||||
## Consequences
|
||||
|
||||
- A tier of thirty-five images is built by as many machines as hold the seat and are online. A
|
||||
machine that is off builds nothing and blocks nothing.
|
||||
- Every holding machine fetches base images from the store and pushes what it builds; the store is
|
||||
reached as a provision, so this is what the provision was for. A machine with a slow link builds
|
||||
slowly, and takes fewer asks for it, which is the point of pulling.
|
||||
- A build's outcome carries which machine built it, so a build that fails on one machine and not
|
||||
another is a fact the record shows, not a mystery.
|
||||
- What got harder: a build's cache is per machine, so a cold machine pays the first pull of every
|
||||
base it has never seen; the artifact store is now asked by several machines at once, and the
|
||||
package registry likewise. Both are provisions and both are made for that.
|
||||
- ADR 0121's *"the mesh's single build machine"* and ADR 0162's *"built by whichever build machine
|
||||
is running — the only one there could be"* were true and are no longer; both records carry a note.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| Two holders of one seat each take one of two asks, and a third ask waits for the first to be idle | the controller's test over the work queue against a real bus: two machines bound to one worker, three asks |
|
||||
| An ask is never delivered to a busy holder | the same test: the busy holder's ask count stays at one until it acknowledges |
|
||||
| A holder that dies mid-work leaves its ask for another | the same test, one holder closed mid-ask |
|
||||
| The asker names no machine | the controller's seat table: `node-build-agent` accepts `build` and the asking side publishes to the seat's accept subject, as the existing tests of `build` already require |
|
||||
| Live | `builds` shows a tier's builds `on` more than one machine within one plan; `seats` shows `node-build-agent` held on every machine with a container runtime — *held on all four machines and a build taken by a workstation's agent, 2026-10-03* |
|
||||
|
||||
## References
|
||||
|
||||
- [Design 25](../03-DESIGN/01-to-be/25-the-bus-on-nats.md) §1 and §5 — the work queue and the queue
|
||||
group of holders this uses as drawn
|
||||
- [Design 18](../03-DESIGN/01-to-be/18-building-a-module.md) — building a module, amended for
|
||||
where a build runs
|
||||
- [ADR 0041](0041-events-are-a-relationship.md), [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md),
|
||||
[ADR 0126](0126-a-module-declares-its-own-seats.md), [ADR 0157](0157-a-build-says-what-it-does-on-the-bus-as-it-happens.md),
|
||||
[ADR 0162](0162-a-merge-produces-a-tiered-plan-the-mesh-keeps.md)
|
||||
- [Issue 175](../04-ISSUES/175-an-announcement-behind-a-long-build-comes-back/00-report.md) — why the
|
||||
worker had one in flight, and why pulling removes the cause rather than the symptom
|
||||
@@ -0,0 +1,120 @@
|
||||
---
|
||||
topic: the tiers
|
||||
status: accepted
|
||||
date: 2026-10-03
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
supersedes-in-part:
|
||||
- 0066-public-routing-is-name-agnostic.md
|
||||
- 0151-a-routes-internal-name-is-composed-under-the-node-that-serves-it.md
|
||||
---
|
||||
|
||||
# 191. The mesh's resolver holds only the mesh's own names; a public name resolves publicly
|
||||
|
||||
> **Progressive insight — 2026-10-03.** The first implementation told the mesh's names from public
|
||||
> ones by their spelling — a name ending in the mesh suffix — and this record said so: the Decision
|
||||
> read *"only names under its own suffix"*, and the roster check *"every name the roster carries ends
|
||||
> in the mesh suffix"*. The mesh needs no such test, nor any per-route name: domains are a node's. A
|
||||
> node has **one internal domain**, `<node>.internal`, and every route on it is a name under that domain
|
||||
> (ADR 0151), answered by one wildcard per node; a node has **one or more public domains**, which public
|
||||
> DNS answers. So the mesh's resolver holds the nodes' internal domains and nothing else, and the roster
|
||||
> carries the machines and no routed name. Both sentences now say that; what was decided — a public
|
||||
> name is never given a private answer — is unchanged.
|
||||
|
||||
## Context
|
||||
|
||||
**[ADR 0066](0066-public-routing-is-name-agnostic.md) published every routed name into internal
|
||||
resolution, mesh-wide, at the address of the node that serves it.** The reason was an internal
|
||||
certificate authority in the lab: it validates by connecting to the name it certifies, and a routed
|
||||
public name that nothing inside the mesh resolved could not be certified.
|
||||
[ADR 0151](0151-a-routes-internal-name-is-composed-under-the-node-that-serves-it.md) kept it:
|
||||
*the roster publishes it as itself, once, at the serving node's address.*
|
||||
|
||||
**So every machine's resolver answered public names with private-network addresses.** On a
|
||||
production mesh on 2026-10-03, each machine's hosts region carried 47 lines of the form
|
||||
`<private address> <label>.<public domain>` — every public name of the control-node at its tunnel
|
||||
address, every public name of the home server at its own. For the machines themselves this is merely
|
||||
a detour: their traffic to a public name goes through the tunnel instead of the internet.
|
||||
|
||||
**For anything that is not a member it is an outage.** The home server's resolver also answers its
|
||||
LAN — a listen address added as a setting on 2026-10-02. A phone on that LAN asked for the mail
|
||||
server's public name, was given the control-node's tunnel address, and could not connect:
|
||||
*couldn't connect to host, port: 10.10.0.1:143*. Every public name of the mesh failed the same way for
|
||||
every non-member on that LAN — a phone, a television, a guest — while every check the mesh runs
|
||||
reported success, because every check runs from a member.
|
||||
|
||||
**And the reason for publishing them is gone.** ADR 0151 gave every route an internal name,
|
||||
`<label>.<serving node>.internal`, under the node's own name. It resolves inside the mesh without any
|
||||
entry of its own, the proxy serves it, and the internal authority certifies it — the proxy has two
|
||||
authorities since 2026-09-25: a public one for public names, the internal one for internal names.
|
||||
Measured the same day: `drive.<control-node>.internal` resolves to the control-node's tunnel address
|
||||
and answers 200 with a certificate that verifies against the internal root. Nothing the mesh runs
|
||||
needs a public name to resolve to a private address. The one consumer that did — an internal
|
||||
authority validating a public name — is the case the second authority removed.
|
||||
|
||||
The predecessor's resolver held exactly this and no more: an address per machine under `.internal`,
|
||||
and everything else forwarded to public resolvers.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. Keep publishing public names; stop the resolver answering the LAN.** Fixes the phone and
|
||||
nothing else. The mesh would still hold a second, private answer for names the public DNS already
|
||||
answers — two answers for one name, which disagree by design and are correct in different places.
|
||||
And it forbids a reasonable setup: a home server's resolver serving its own LAN.
|
||||
|
||||
**2. Answer per source: private addresses to members, public ones to everyone else.** Split-horizon
|
||||
by client. It is what a resolver serving two audiences would need *if* the private answer were worth
|
||||
giving. It is not — option 3 shows nothing needs it — and it makes a name's address depend on who
|
||||
asks, which is the hardest kind of fault to see from a member.
|
||||
|
||||
**3. The mesh's resolver holds only the mesh's own domain.** Names under the mesh suffix — machines,
|
||||
and routes' internal names under them — resolve to private addresses. Every other name, including
|
||||
every public name the mesh serves, is forwarded and resolves publicly. Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**The mesh's resolver holds each node's internal domain and nothing else** — `<node>.internal` and
|
||||
everything under it, at that node's private address. A machine's name,
|
||||
and through it every `<label>.<node>.internal`, resolve to that machine's private address. **A public
|
||||
name is never given a private answer by the mesh**: it resolves through public DNS to the public
|
||||
address, from members and non-members alike.
|
||||
|
||||
This replaces ADR 0066's clause *"when the proxy is granted a name, the mesh publishes that name →
|
||||
the node that serves it into internal resolution, mesh-wide"*, and ADR 0151's *"the roster publishes
|
||||
it as itself, once, at the serving node's address."* Everything else in both stands: the label, the
|
||||
node's public domain, the composition, and the internal name under the serving node.
|
||||
|
||||
**Inside the mesh, a route is reached by its internal name.** A container or a validator that must
|
||||
reach a routed service inside the mesh uses `<label>.<node>.internal`; the internal authority
|
||||
certifies that name, and a public authority certifies the public one. A mesh with no public
|
||||
reachability — the lab — certifies its internal names and has no public names to resolve.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **A resolver serving a LAN is safe.** What it adds to public resolution is the mesh's own domain,
|
||||
which no public resolver answers.
|
||||
- **A member reaches a public name over the internet, as anyone does.** A route the proxy restricts
|
||||
to the private network is reached by its internal name, never by its public one — a public name
|
||||
is, by this decision, public.
|
||||
- **The internal authority certifies internal names only.** It was the only consumer of a public
|
||||
name's private answer; the proxy's second authority already took that role away from it.
|
||||
- **Public names leave every machine's hosts region** on the first push after the change.
|
||||
Containers do not move with it: the roster is not part of a container's identity
|
||||
([ADR 0148](0148-the-meshs-names-are-resolved-not-copied-into-containers.md)).
|
||||
|
||||
**How each is checked:**
|
||||
|
||||
- **The roster:** the controller's tests assert that the roster names the machines and nothing
|
||||
else — a routed name in it, public or internal, fails the build.
|
||||
- **On a machine:** asking the machine's resolver for a public name the mesh serves returns the
|
||||
public address, and asking it for that route's internal name returns the private one. Asked from a
|
||||
non-member on a LAN the resolver answers, the first must hold as well.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0066 — public routing is name-agnostic](0066-public-routing-is-name-agnostic.md), whose
|
||||
propagation clause this replaces.
|
||||
- [ADR 0151 — a route's internal name is composed under the node that serves it](0151-a-routes-internal-name-is-composed-under-the-node-that-serves-it.md),
|
||||
which made the private answer unnecessary.
|
||||
- [Connectivity design §2 and §5](../03-DESIGN/01-to-be/08-connectivity.md), amended alongside this
|
||||
record.
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-03
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md
|
||||
---
|
||||
|
||||
# 192. A tools bundle declares what it is given, and the runtime hands it to that bundle alone
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md) put one
|
||||
runtime on every node serving every module's tools from a bundle, and
|
||||
[ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)
|
||||
said a module's own code is bundles and never an image. The two holders that moved first
|
||||
([to-be 38](../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP4) needed nothing a
|
||||
bundle does not have: a fixed path, and root. Research
|
||||
[020](../01-RESEARCH/020-what-a-bundled-tool-is-given/00-overview.md) measured the rest before
|
||||
they move: thirty-three modules still run their tools as a container on the runtime's image, and
|
||||
thirty-one of them are handed, through the container's environment and mounts, things a bundle
|
||||
has no way to receive — the module's configuration file, its own secret as a file, the service's
|
||||
address with the port the mesh chose, a provision's address, a directory of grants. Every one of
|
||||
those is a file the mesh already places on the machine or a value the controller already composes
|
||||
for the container, per module per machine, from references the manifest writes: a placed
|
||||
directory, a chosen port. And the SDK's tool contributor is a function of an environment that the
|
||||
runtime calls without one, so every bundle reads the process's four words.
|
||||
|
||||
Without a rule, each of the thirty-one would answer the question its own way, and the runtime's
|
||||
process would be the one place where every module's paths meet.
|
||||
|
||||
> **Progressive insight — 2026-10-03.** The context above calls the thirty-one remaining containers
|
||||
> tool containers handed what a bundle cannot receive. Measured the same day while building this
|
||||
> record: nine of them run only tools; three run a main of their own; twenty import, beside their
|
||||
> tools, the module's own long-running code — event handlers that subscribe on the bus and
|
||||
> provisioners that act on grants — under the module's own bus identity, and some reach their
|
||||
> service by a container network name or need a package the image installed. That code is not a
|
||||
> tool and is not this record's to move: under
|
||||
> [ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)
|
||||
> §3 it is a `process` bundle, and how it is given its credential, its words and its reach is the
|
||||
> open question of [design 38](../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP4c.
|
||||
> Decision 4 applies to these containers' tools; the containers themselves go when their other
|
||||
> code has moved. The decision and its options stand.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **The bundle declares its environment on its artifact, and the mesh composes it as a
|
||||
container's.** Chosen. The tools artifact gains `env`: names to values, the values written with
|
||||
the references the composer already resolves for a container — `${dir:…}`, `${port:…}` — and
|
||||
what was a mount target becomes the host path itself. The controller composes one environment
|
||||
per bundle per machine into the runtime's declaration. The runtime hands it to that bundle's
|
||||
contributor, or to the child it launches, and to nothing else. The tool code reads the names it
|
||||
read before.
|
||||
2. **The runtime derives it from the module's placed manifest** — a conventional word per
|
||||
directory and port, no new field. Rejected: a convention the thirty-one tools must be rewritten
|
||||
to, the runtime learning the composer's job, and a module that names its file one way and a
|
||||
module that names it another needing different words regardless.
|
||||
3. **The tool asks the controller over the bus.** Rejected: a tool that cannot start until the
|
||||
bus answers fails in the one case tools exist for, and a secret crossing the bus to reach a file
|
||||
already on the machine is a disclosure for nothing.
|
||||
4. **Leave each module to its own device.** Rejected by the measurement: thirty-one modules, one
|
||||
question.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A tools bundle says what it is given, on its artifact.** `build.artifacts[].env` names the
|
||||
words the bundle reads and their values. A value is a path or a constant, composed with the
|
||||
references a container's environment may use; **never a secret's content.** A secret reaches a
|
||||
tool the way it reaches a container: as a file the mesh places, whose path the environment names.
|
||||
A bundle that declares no `env` is given nothing beyond the runtime's own words, which is what the
|
||||
two holders that moved have.
|
||||
|
||||
**2. The mesh composes it, per bundle per machine, as it composes a container's.** The same
|
||||
references, resolved the same way, to the host's own paths. The composed environment travels in
|
||||
the node's declaration beside the bundle's archive; a change to it is a change to the bundle for
|
||||
the purpose of `restart-on`.
|
||||
|
||||
**3. The runtime hands each bundle its own environment, and nothing of another's.** A bundle
|
||||
imported into the runtime's process receives it as the argument its contributor is written to
|
||||
take; a bundle launched as a child ([ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md) §2)
|
||||
receives it as the child's environment, over the runtime's own words. The runtime's process
|
||||
environment is not where a module's words go, and a tool that reads the process's environment
|
||||
rather than the one it was handed finds the runtime's four words and no module's.
|
||||
|
||||
**4. The remaining tool containers move in one change** after this is built, each proven by its
|
||||
tools answering from the runtime, and the registration gate of
|
||||
[to-be 38](../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP2 then refuses the
|
||||
container shape for every module, as ADR 0188 already provides.
|
||||
|
||||
> **The mechanism changed — 2026-10-03, by ADR 0193.** Decision 3's imported path — the environment
|
||||
> handed to an imported bundle's contributor — has nothing left to do: every served bundle is
|
||||
> launched, and a launched bundle's environment is its own. The decision stands.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The manifest gains one field on one artifact kind; the composer gains one more thing to resolve
|
||||
with references it has; the runtime gains the hand-off and the separation. The thirty-one modules'
|
||||
tool code does not change, and their conversion is the move of a container's `env` with its
|
||||
mounts folded into host paths.
|
||||
- A tool's inputs become legible in the manifest where its container hid them in mounts: what a
|
||||
module's tools read is declared beside what the module writes.
|
||||
- What got harder: the runtime must keep thirty-one environments apart in one process, and a
|
||||
bundle's author must not reach for the process's environment. The separation is a rule the
|
||||
runtime's test holds, not a property of the language.
|
||||
- `MESH_BROKER_FILE` is not a bundle's to declare: the runtime speaks with the node's credential
|
||||
([ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md)), and
|
||||
a module's own bus credential went with its container.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A value in a bundle's `env` is a path or a constant, never a secret's content | the catalogue's manifest check refuses a `${secret:…}` reference in a bundle's `env`, naming this record |
|
||||
| The composer resolves a bundle's `env` as a container's | the controller's composition test: one module, one bundle with `${dir:…}` and `${port:…}` in its `env`, the declaration carrying the host paths and the chosen port |
|
||||
| Each bundle sees its own environment and no other's | the runtime's test: two bundles with different `env`, loaded in one runtime, each answering with its own words and none of the other's; the same for a launched bundle |
|
||||
| A change to a bundle's environment restarts the runtime | the composition test above, with `restart-on` naming the bundle |
|
||||
| Live | a module whose tools read a configuration file and a token file answers from the runtime on one machine with no container |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md),
|
||||
[ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)
|
||||
- Research [020](../01-RESEARCH/020-what-a-bundled-tool-is-given/00-overview.md) — the measurement
|
||||
and the options
|
||||
- [to-be 38](../03-DESIGN/01-to-be/38-building-the-operators-machine.md) — where the work is listed
|
||||
+88
@@ -0,0 +1,88 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-03
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md
|
||||
---
|
||||
|
||||
# 193. Every bundle the runtime serves is launched, and the runtime knows no language
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)
|
||||
§2 made a served bundle a process that speaks MCP over stdio, and kept one exception: a TypeScript
|
||||
bundle may be imported into the runtime's own process, "a shortcut over the same contract". Every
|
||||
module's tools today take the shortcut, and it is where the day's defects came from:
|
||||
|
||||
- [Issue 209](../04-ISSUES/209-a-bundles-own-sdk-copy-registers-into-a-registry-the-runtime-never-reads/00-report.md):
|
||||
an imported bundle's own copy of the SDK registered into a registry the runtime never read; fixed
|
||||
by a resolve hook that redirects every bundle's SDK import to the runtime's copy.
|
||||
- [ADR 0192](0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md):
|
||||
thirty modules' environments in one process had to be kept apart by an SDK change and runtime
|
||||
bookkeeping, where a process of its own has an environment of its own by construction.
|
||||
- One faulty module can block or crash every other module's tools on its node.
|
||||
|
||||
And the shortcut ties the runtime to Node.js: only a JavaScript runtime can import JavaScript. The
|
||||
operator's direction on 2026-10-03: *a module's tools are written in any language and the builder
|
||||
builds them; the runtime runs them all and announces them; it should be fully language agnostic,
|
||||
and node-tools can be rewritten in Go.*
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep the shortcut.** Rejected: it is the cause of the three defects above, and it pins the
|
||||
runtime's language.
|
||||
2. **Launch every served bundle; the runtime knows how to start each language** (`node` for a
|
||||
`.js`, exec for a binary). Rejected: the runtime would hold a table of interpreters, and a
|
||||
runtime in Go would carry Node.js's knowledge for nothing.
|
||||
3. **Launch every served bundle, and the build makes each served entrypoint executable.** Chosen.
|
||||
A compiled language's binary is executable already; for an interpreted one the toolchain writes
|
||||
a launcher beside the entrypoint — for TypeScript, a file that imports the entrypoint and serves
|
||||
what it registered over stdio, using the bundle's own SDK. The runtime execs what it is given.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. Every bundle the node's runtime serves is a child process speaking MCP over stdio.** The
|
||||
in-process shortcut of ADR 0188 §2 is withdrawn. Everything else ADR 0188 §2 says — `tools/list`,
|
||||
`tools/call`, `<seat>.<verb>` naming a seat's verb, the runtime serving each on the bus — stands.
|
||||
|
||||
**2. The runtime knows no language.** It is given an executable per served entrypoint and starts
|
||||
it, with that bundle's environment ([ADR 0192](0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md))
|
||||
over its own words, and the module it serves it as. What makes an entrypoint executable is the
|
||||
toolchain's business: a binary is one; an interpreted language's toolchain writes a launcher.
|
||||
|
||||
**3. A launched bundle is told the module it serves as**, so that what it lists unprefixed is that
|
||||
module's own tools and a seat's verbs are always `<seat>.<verb>`, whichever it registered first.
|
||||
|
||||
**4. The runtime may be written in any language.** Nothing it does needs it to share a language
|
||||
with a bundle; the mesh's runtime moves to Go, against this contract, once the contract is proven
|
||||
in the runtime that exists.
|
||||
|
||||
## Consequences
|
||||
|
||||
- A process per served module per node. On the busiest machine that is a score of small children
|
||||
where there was one process; a Go bundle costs a fraction of a Node.js one.
|
||||
- The SDK resolve hook (issue 209) and the per-registration environment hand-off (ADR 0192 §3,
|
||||
imported bundles) have nothing left to do and go; a launched bundle's environment is its own.
|
||||
- A module's TypeScript tool code does not change: it registers as before, and the generated
|
||||
launcher serves what it registered.
|
||||
- A bundle that crashes or hangs takes only its own tools down, and is started again on its next
|
||||
call, as ADR 0188 already provides for a launched bundle.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| Every served bundle is launched | the runtime's tests: a TypeScript bundle and a bundle in a second language, both launched, both answering over a real bus; a non-executable entrypoint is refused by name |
|
||||
| The runtime knows no language | the runtime holds no interpreter: it execs the path it is given (code review; the Go runtime has no Node.js dependency at all) |
|
||||
| A TypeScript served entrypoint is executable | the builder's test: a TypeScript bundle's served entrypoint has a launcher beside it, mode 0755 |
|
||||
| A seat's verbs are named as the seat's whichever registers first | the SDK's test: a bundle registering its seat first and its own tools second lists `<seat>.<verb>` and its own tools unprefixed |
|
||||
| Live | the packet filter's and intrusion prevention's seat verbs and the moved tools answer from launched bundles on every machine |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md),
|
||||
[ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md),
|
||||
[ADR 0192](0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md)
|
||||
- [to-be 38](../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP4d
|
||||
+157
@@ -0,0 +1,157 @@
|
||||
---
|
||||
topic: the tiers
|
||||
status: accepted
|
||||
date: 2026-10-03
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
supersedes-in-part:
|
||||
- 0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md
|
||||
extends: 0191-the-meshs-resolver-holds-only-the-meshs-own-names.md
|
||||
---
|
||||
|
||||
# 194. The mesh has one resolver, and every node asks it for the mesh's names
|
||||
|
||||
> **Narrowed, not replaced — 2026-10-03.** How a node asks is decided again by
|
||||
> [ADR 0196](0196-a-node-asks-the-meshs-resolver-first-and-a-public-one-only-when-it-is-silent.md): every
|
||||
> node and container asks `mesh-resolver` first and a public resolver only when it is silent. There is
|
||||
> no `systemd-resolved` module and no runtime `dns` naming `mesh-resolver`, and step 2 of the migration
|
||||
> reads as 0196 states it. Option 2 below was rejected for a laptop with its tunnel down resolving
|
||||
> nothing; a public resolver listed second answers exactly then. The one resolver, its placement and
|
||||
> the retirement of every per-node copy stand.
|
||||
|
||||
## Context
|
||||
|
||||
**Every node runs its own resolver and holds its own copy of the mesh's names.** On the production
|
||||
mesh on 2026-10-03, each of the four nodes held `node-dns-resolver` with dnsmasq, fed on every push
|
||||
with a zones file (one wildcard per node) and a region of `/etc/hosts` (the machines), and pointed
|
||||
its own `/etc/resolv.conf` at itself. The controller computes the names once; four daemons then hold
|
||||
four copies, each read in its own way.
|
||||
|
||||
**Every resolution fault found that day was a copy disagreeing with the truth, not the truth being
|
||||
wrong:**
|
||||
|
||||
- **A copy read once.** dnsmasq reads `/etc/hosts` at start. After the controller stopped publishing
|
||||
public names ([ADR 0191](0191-the-meshs-resolver-holds-only-the-meshs-own-names.md)), every node's
|
||||
hosts file was right and every resolver still answered the mail server's public name with a
|
||||
tunnel address, until each was restarted.
|
||||
- **A copy beside other copies.** On the workstation, a name resolved to two addresses in rotation:
|
||||
the mesh's region gave the tunnel address, and two lines the operator had written before the mesh
|
||||
existed — one in `/etc/hosts`, one in a file the resolver also reads — gave the LAN address. A
|
||||
comment beside one of them said to delete it once the mesh took over; nothing made that happen.
|
||||
- **A copy that became somebody else's resolver.** The home server's resolver also answers its LAN
|
||||
(a listen address added 2026-10-02), and the LAN's router hands that address out as the only DNS
|
||||
server. Every phone and television on the LAN resolved through a mesh node's private copy, which is
|
||||
how ADR 0191's outage reached them.
|
||||
|
||||
**And the overlay already has one centre.** Every node has exactly one tunnel peer — the anchor —
|
||||
and routes the whole private range through it. Two nodes on the same LAN reach each other through
|
||||
the anchor. So a name under `.internal` is only ever useful while the anchor is reachable: a resolver
|
||||
anywhere else adds a copy without adding an answer anybody can use.
|
||||
|
||||
**What a node asks is already a separate role.** The connectivity design split *serving* (answers
|
||||
the names) from *asking* (decides what the machine asks), because systemd-resolved cannot answer a
|
||||
wildcard and can only route the mesh's suffix to something that can
|
||||
([connectivity §2](../03-DESIGN/01-to-be/08-connectivity.md)). ADR 0121 kept them as two seats,
|
||||
`node-dns-resolver` and `node-resolver-config`, both at node scope. No node runs systemd-resolved
|
||||
today; each writes `/etc/resolv.conf` as a plain file pointing at its own dnsmasq.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. Keep a resolver on every node, and make the copies more careful.** Restart on every file it
|
||||
reads, own every file it reads, refuse to listen on a LAN. Each is a fix for one way a copy goes
|
||||
stale, and the next way is not on the list yet. It keeps four answers to one question.
|
||||
|
||||
**2. One resolver for the mesh, and every node sends it every query.** The simplest asking side —
|
||||
`resolv.conf` names the mesh's resolver and nothing else. Rejected: public resolution then depends on
|
||||
the tunnel. A laptop whose tunnel is down could resolve nothing at all, and a public name would take
|
||||
a detour through the anchor for no reason ADR 0191 left standing.
|
||||
|
||||
**3. One resolver for the mesh's names; each node asks it for those only.** The mesh's resolver holds
|
||||
every node's internal domain. Each node's asking role routes the mesh's suffix to it and every other
|
||||
name to public resolvers. Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**The mesh has one resolver.** It is a module holding a new mesh-scoped seat, **`mesh-resolver`**
|
||||
(capacity one). It holds each node's internal domain — `<node>.internal` and everything under it, at
|
||||
that node's private address ([ADR 0191](0191-the-meshs-resolver-holds-only-the-meshs-own-names.md))
|
||||
— and listens on the private network only. It is placed on the node every tunnel converges on, so
|
||||
that it shares the overlay's single point rather than adding one. Which daemon fills the seat stays
|
||||
the module's business, as the connectivity design says.
|
||||
|
||||
**Every node asks it for the mesh's names and nothing else.** `node-resolver-config` routes the
|
||||
mesh's suffix to `mesh-resolver` and leaves every other name with public resolvers.
|
||||
|
||||
**Why a stub on every node.** `resolv.conf` cannot route by domain: the C library asks the servers it
|
||||
lists in order, for every name, and moves to the next only when one does not answer — an NXDOMAIN
|
||||
from the first is final. Listing `mesh-resolver` first sends every public name through the tunnel
|
||||
(option 2); listing a public resolver first means `.internal` is never asked of the mesh. Something on
|
||||
the node has to look at the name before choosing a server, and that is a stub resolver. Keeping
|
||||
dnsmasq for it would keep a daemon that reads hosts files and can be told to answer a LAN — the two
|
||||
ways copies went wrong. systemd-resolved holds no names of its own, routes by domain natively (a
|
||||
routing domain `~<suffix>` on the server that answers it), and is part of systemd, already installed
|
||||
on every node and enabled on none.
|
||||
|
||||
**So the asking side is a `systemd-resolved` module**, claiming `node-resolver-config` — the same claim
|
||||
as the `resolv-conf` module it replaces, so the mesh refuses both on one node. It enables the service,
|
||||
writes its configuration (the mesh resolver for the suffix, public resolvers for everything else), and
|
||||
writes `/etc/resolv.conf` as a file naming the stub — a file the module owns, not a link to one.
|
||||
|
||||
**A container asks the mesh's resolver directly.** The container runtime cannot use a loopback stub
|
||||
and drops its routing domains, so the runtime's `dns` names `mesh-resolver`, which forwards public
|
||||
names for the containers that ask it. This is the one place a public name passes through the mesh,
|
||||
and it is stated rather than hidden.
|
||||
|
||||
**`node-dns-resolver` is retired**, and with it every per-node copy: the zones file, the mesh's region
|
||||
of `/etc/hosts` (the floor connectivity §2 already planned to remove), and the daemon on every node
|
||||
but the one holding `mesh-resolver`. This narrows ADR 0121's *"the-dns-port → node-dns-resolver"*:
|
||||
the serving role keeps its distinction from the asking role and moves to mesh scope, as ADR 0121 did
|
||||
for the private network.
|
||||
|
||||
**A LAN's resolver is not the mesh's.** No device that is not a member can reach a private address,
|
||||
so no member's resolver answers a LAN on the mesh's behalf. A router that hands out a node's address
|
||||
as a LAN's DNS server is pointed elsewhere before that node stops answering.
|
||||
|
||||
**The order is fixed, because every step before the last leaves a working resolver:**
|
||||
|
||||
1. `mesh-resolver` is assigned and answers on the private network.
|
||||
2. Each node's `node-resolver-config` moves from `resolv-conf` to `systemd-resolved`, and the container
|
||||
runtime's `dns` to `mesh-resolver`.
|
||||
3. A LAN whose router points at a node's resolver is pointed at its router or a public resolver.
|
||||
4. `node-dns-resolver` is unassigned from every node, and the hosts region is withdrawn.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **One answer per name.** A name is wrong in one place or right everywhere; no node can hold a copy
|
||||
that disagrees, and no operator file on a node is read by the mesh's resolver.
|
||||
- **The anchor down means no `.internal` names** — which it already meant for `.internal` traffic,
|
||||
since every tunnel goes through it. Public resolution on every node is unaffected.
|
||||
- **A container's public resolution depends on the mesh's resolver.** Accepted, and named in the
|
||||
decision; a container that must resolve public names with the tunnel down is the case it costs.
|
||||
- **Every node runs systemd-resolved**, through the `systemd-resolved` module. It is installed
|
||||
everywhere already and enabled nowhere; the mesh still ships no resolver of its own.
|
||||
- **The runtime's `dns` changes once per node**, which the runtime reads only at start. With
|
||||
`live-restore` already on, that restart keeps every container running.
|
||||
- **A LAN loses a resolver it had borrowed.** The router change is an explicit step, done through
|
||||
the module that manages the router, before the node's resolver goes.
|
||||
|
||||
**How each is checked:**
|
||||
|
||||
- **One holder:** the seat has capacity one, so a second assignment is refused by the controller.
|
||||
- **Asking:** on each node, `resolvectl` shows the tunnel's link with `mesh-resolver` and the suffix as
|
||||
its routing domain; a name under `.internal` is answered by it, and a public name is answered
|
||||
without it (its query log shows no public name from a node).
|
||||
- **No copies:** no node but the holder answers DNS on a private or LAN address — every other node's
|
||||
port 53 is systemd-resolved's loopback stub and nothing else — and no node's `/etc/hosts` carries a
|
||||
mesh region.
|
||||
- **A LAN:** the router's DHCP DNS option names no node's address.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0191](0191-the-meshs-resolver-holds-only-the-meshs-own-names.md) — what the mesh's resolver
|
||||
holds; this record decides where it runs and how nodes reach it.
|
||||
- [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md) — the two
|
||||
resolver seats, and the private network's move to mesh scope this mirrors.
|
||||
- [Connectivity §2](../03-DESIGN/01-to-be/08-connectivity.md) — serving and asking as two roles;
|
||||
amended alongside this record.
|
||||
- [The seats](../03-DESIGN/01-to-be/26-the-seats.md) — the seat table, amended alongside.
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-03
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0152-the-operators-surface-is-a-module-the-console.md
|
||||
---
|
||||
|
||||
# 195. The mesh's tools are found by address, not announced whole
|
||||
|
||||
## Context
|
||||
|
||||
The console answers MCP on a machine's loopback ([ADR 0152](0152-the-operators-surface-is-a-module-the-console.md),
|
||||
[to-be 34](../03-DESIGN/01-to-be/34-the-console.md)) and announces, at a session's start, every tool
|
||||
the mesh can say it has: 228 on 2026-10-03, 110 KB, taken once. Three things are wrong with that,
|
||||
measured in research [021](../01-RESEARCH/021-finding-a-tool-in-the-mesh/00-overview.md):
|
||||
|
||||
- **Size.** Only one client's habit of deferring long lists keeps them out of the model's context.
|
||||
- **Ambiguity.** A module on two machines is listed once, `node` optional, *whichever answers* — for
|
||||
postgres and mssql, whose instances hold different data, a call that names no machine asks an
|
||||
arbitrary one.
|
||||
- **Staleness.** A tool that arrives after the session started is not listed until it reconnects.
|
||||
|
||||
The mesh already has the structure a caller needs: seats held once for the mesh, seats held once per
|
||||
machine ([ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md)), and
|
||||
modules assigned to machines, each assignment issued its own subjects
|
||||
([ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md)).
|
||||
The operator's direction: *tools are discoverable, in layers, and asking novox's postgres is not asking
|
||||
ace's.*
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. Keep the flat list and rely on the client. Rejected: the ambiguity and the staleness stay, and it
|
||||
is one client's behaviour.
|
||||
2. One tool per assignment, the machine in the name. Rejected: the list multiplies, and an address in
|
||||
a tool's name meets the API's limit — letters, digits, `_` and `-`, at most 64 characters.
|
||||
3. **A fixed handful of tools that walk the mesh's structure, the address an argument.** Chosen.
|
||||
4. MCP resources or prompts. Rejected: unevenly supported, and an agent acts through tools.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. Everything the mesh answers has one address, by the layer it lives in:**
|
||||
|
||||
| layer | address | answered by |
|
||||
|---|---|---|
|
||||
| a seat held once for the mesh | `<seat>.<verb>` | that seat's holder |
|
||||
| a seat held once per machine | `<node>/<seat>.<verb>` | that machine's holder |
|
||||
| a module assigned to a machine | `<node>/<module>.<tool>` | that assignment |
|
||||
| a module whose instances are interchangeable (ADR 0160) | `<module>.<tool>` as well | any of them |
|
||||
|
||||
**A call to a module that is not interchangeable names its machine, or is refused** naming the machines
|
||||
it runs on. "Whichever answers" is no longer an answer for state a machine holds.
|
||||
|
||||
**2. The console announces a fixed set of tools, not the catalogue:**
|
||||
|
||||
- **`mesh_overview`** — the mesh's seats with their verbs, and its machines;
|
||||
- **`mesh_machine`** — one machine: the node seats it holds and the modules assigned to it, each with
|
||||
its tools by name;
|
||||
- **`mesh_search`** — words in, matching addresses out with one line each, across every layer;
|
||||
- **`mesh_describe`** — one address in, its description and argument schema out;
|
||||
- **`mesh_call`** — an address and its arguments in, the answer out, with the machine that gave it.
|
||||
|
||||
Each is answered from the mesh when it is asked, so a tool that arrived a minute ago is found without
|
||||
the client reconnecting. The names are the API's kind of name; addresses never have to be.
|
||||
|
||||
**3. The flat catalogue stays reachable, not announced:** the `mesh` client and a console setting can
|
||||
still list it whole, for a person reading it or a client that wants it. An agent pointed at the console
|
||||
sees the five.
|
||||
|
||||
> **The mechanism changed — 2026-10-03, by ADR 0197.** Where the console learns what exists: not
|
||||
> from the catalogue's roster and the controller's printed lists, but from every runtime announcing
|
||||
> itself on the bus in the NATS services protocol, checked against the controller's records read as
|
||||
> JSON. The addresses and the five tools stand.
|
||||
|
||||
## Consequences
|
||||
|
||||
- An agent spends a call or two finding a tool it does not know, and none on one it does; the context
|
||||
no longer carries 110 KB it mostly never uses.
|
||||
- The ambiguity is closed by the address, not by a description asking the agent to remember `node`.
|
||||
- What got harder: an agent that once saw a tool's schema up front now asks for it. `mesh_describe` and
|
||||
`mesh_search` answering with the schema of a close match keep that to one call.
|
||||
- The discovery verbs are the console's; the mesh's own records — seats, machines, assignments — are
|
||||
the controller's, and the console asks it rather than keeping a copy.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| The console announces five tools | the console's test: `tools/list` answers exactly the five |
|
||||
| An address resolves to one subject per layer | the console's tests: a mesh seat, a node seat, an assignment, an interchangeable module, each called by address over a real bus |
|
||||
| A non-interchangeable module without a machine is refused, naming its machines | the same tests |
|
||||
| A tool that arrives after the session started is found | a test registering a module after the console's first answer and finding it by `mesh_search` |
|
||||
| Live | from a fresh session, *which databases does novox's postgres hold* is answered by novox's postgres, found through the five |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0152](0152-the-operators-surface-is-a-module-the-console.md),
|
||||
[ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md),
|
||||
[ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md)
|
||||
- Research [021](../01-RESEARCH/021-finding-a-tool-in-the-mesh/00-overview.md)
|
||||
- [to-be 34](../03-DESIGN/01-to-be/34-the-console.md)
|
||||
+98
@@ -0,0 +1,98 @@
|
||||
---
|
||||
topic: the tiers
|
||||
status: accepted
|
||||
date: 2026-10-03
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
supersedes-in-part:
|
||||
- 0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md
|
||||
---
|
||||
|
||||
# 196. A node asks the mesh's resolver first, and a public one only when it is silent
|
||||
|
||||
## Context
|
||||
|
||||
**[ADR 0194](0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md) gave the
|
||||
mesh one resolver and had each node ask it for the mesh's names only.** Because `resolv.conf` cannot
|
||||
route by domain, that needed a stub on every node — a `systemd-resolved` module — and a separate
|
||||
`dns` for the container runtime, which cannot use a loopback stub. It rejected the simpler shape,
|
||||
every node sending every query to the mesh's resolver, on the grounds that *"a laptop whose tunnel is
|
||||
down could resolve nothing at all."*
|
||||
|
||||
**That is true only of a `resolv.conf` naming the mesh's resolver alone.** The C library asks the
|
||||
servers it lists in order and moves to the next when one does not answer within its timeout. A public
|
||||
resolver listed second is asked exactly when the mesh's is unreachable — the anchor down, the tunnel
|
||||
down, a laptop behind a captive portal that has not let the tunnel up — and never otherwise. An answer
|
||||
from the first, including "no such name", is final, so `.internal` is never asked of a public resolver
|
||||
while the mesh's answers.
|
||||
|
||||
**And the container runtime copies a machine's resolvers into its containers when they are not
|
||||
loopback addresses.** With the mesh's resolver and a public one listed, every container gets both, as
|
||||
they are, with nothing configured for the runtime.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**1. Keep ADR 0194's stub.** Public names never touch the mesh, and a node with the anchor down
|
||||
resolves public names at full speed. It costs a module and a running service on every node, a second
|
||||
configuration for containers, and the one asymmetry ADR 0194 had to state — containers' public names
|
||||
through the mesh, nodes' not.
|
||||
|
||||
**2. Every node asks the mesh's resolver for everything, with a public resolver as the silent
|
||||
fallback.** One server answers every node and every container; nothing on a node routes, holds names,
|
||||
or runs. Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**A node's `/etc/resolv.conf` names the mesh's resolver first and a public resolver second, with a
|
||||
short timeout and a single attempt.** It is written by the module holding `node-resolver-config` — the
|
||||
existing `resolv-conf` — which now names `mesh-resolver`'s address instead of the machine's own. The
|
||||
mesh's resolver answers the mesh's names from what it holds and forwards every other name, giving the
|
||||
public answer ([ADR 0191](0191-the-meshs-resolver-holds-only-the-meshs-own-names.md) is unchanged: no
|
||||
public name gets a private answer).
|
||||
|
||||
**Containers take the same two resolvers from their machine.** The container runtime's own `dns`
|
||||
setting is not written; the runtime copies the machine's non-loopback resolvers into every container.
|
||||
|
||||
**This replaces, from ADR 0194:** the asking side as a stub (*"So the asking side is a
|
||||
`systemd-resolved` module"*), the container runtime's `dns` naming `mesh-resolver`, and step 2 of the
|
||||
migration as written. There is no `systemd-resolved` module. Everything else in ADR 0194 stands — one
|
||||
`mesh-resolver`, on the node every tunnel converges on, holding each node's internal domain, the
|
||||
retirement of `node-dns-resolver` and every per-node copy, and a LAN's resolver not being the mesh's.
|
||||
|
||||
**The migration, as it now reads:**
|
||||
|
||||
1. `mesh-resolver` is assigned and answers on the private network.
|
||||
2. Each node's `resolv-conf` names `mesh-resolver` first and a public resolver second.
|
||||
3. A LAN whose router points at a node's resolver is pointed at its router.
|
||||
4. `node-dns-resolver` is unassigned from every node, and the hosts region is withdrawn.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **Every name a node or container asks goes through the anchor while it is up.** A public lookup
|
||||
takes a few milliseconds longer than asking a public resolver directly, and the mesh's resolver sees
|
||||
every name its nodes look up. It is the operator's own server.
|
||||
- **With the anchor unreachable, each lookup waits out one timeout, then resolves publicly.**
|
||||
`.internal` names fail then — as `.internal` traffic does, every tunnel going through the anchor.
|
||||
- **A LAN is unaffected by this choice.** Devices that are not members never read a node's
|
||||
`resolv.conf`; they get their resolver from their router, which step 3 points at itself.
|
||||
- **Nothing new runs on a node.** No stub, no module, no per-node configuration for containers.
|
||||
- **The runtime's `dns` key goes with `node-dns-resolver`.** The dnsmasq module wrote it into the
|
||||
runtime's configuration; unassigning that module in step 4 withdraws it, and the runtime reads the
|
||||
change only when it next starts — with `live-restore` on, that restart keeps every container
|
||||
running.
|
||||
|
||||
**How each is checked:**
|
||||
|
||||
- **Order:** each node's `/etc/resolv.conf` lists `mesh-resolver`'s private address first and a public
|
||||
resolver second, and nothing else.
|
||||
- **Fallback:** with `mesh-resolver` unreachable from a node, a public name still resolves there, after
|
||||
the timeout.
|
||||
- **Containers:** a container started on a node lists the same two resolvers.
|
||||
- **A LAN:** the router's DHCP DNS option names the router, not a node.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0194](0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md) — the one
|
||||
resolver; this record replaces how nodes and containers ask it.
|
||||
- [ADR 0191](0191-the-meshs-resolver-holds-only-the-meshs-own-names.md) — what the resolver holds.
|
||||
- [Connectivity §2](../03-DESIGN/01-to-be/08-connectivity.md), amended alongside this record.
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-03
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0195-the-meshs-tools-are-found-by-address-not-announced-whole.md
|
||||
---
|
||||
|
||||
# 197. Every tool announces itself on the bus, in the NATS services protocol
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0195](0195-the-meshs-tools-are-found-by-address-not-announced-whole.md) gave every tool an
|
||||
address and the console five tools to find them. Where the console learns what exists, it inherited
|
||||
from [to-be 34](../03-DESIGN/01-to-be/34-the-console.md) §3: ask the catalogue for its roster, ask
|
||||
each module on the roster for its `tools`, and read the machines and assignments from the
|
||||
controller's printed `node list` and `module list`. Built that way on 2026-10-03, it worked and showed
|
||||
what is wrong with it:
|
||||
|
||||
- **It asks what should exist and infers what does.** The roster holds every module the catalogue
|
||||
ever registered; 47 of them were reported "not answering" on 2026-10-03, most with no tools at all
|
||||
and several retired.
|
||||
- **It parses prose.** Two of the controller's answers are text for a person, and a reworded column
|
||||
breaks discovery.
|
||||
|
||||
The bus already knows what answers. NATS has a services protocol for exactly this: a service answers
|
||||
`$SRV.PING` and `$SRV.INFO` — every instance, on one request — with its name, its instance, and every
|
||||
endpoint's subject and metadata, in a published format the NATS tools read. The operator's direction:
|
||||
*every tool announces itself; the mesh has the full picture, so nothing should be inferred or parsed.*
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **Keep asking the roster, and give the controller JSON answers.** Fixes the parsing, keeps the
|
||||
inference.
|
||||
2. **Re-serve every tool through a NATS services library.** The announcement for free, but every
|
||||
runtime's serving path rewritten around a library, in two languages, for no change in behaviour.
|
||||
3. **Every runtime answers the services protocol's discovery subjects with what it serves; serving
|
||||
is unchanged.** Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. What answers announces itself.** Every runtime that serves tools — each machine's tool runtime,
|
||||
the per-module runtimes still in containers, and the controller for the seat it holds — answers
|
||||
`$SRV.PING` and `$SRV.INFO` in the NATS services format: one service per module or seat it serves,
|
||||
named for it, its instance the machine; one endpoint per tool, its subject and queue exactly as
|
||||
served, its metadata the tool's description, argument schema, the machine, the seat and scope where
|
||||
it is a seat's verb, and whether the module's instances are interchangeable.
|
||||
|
||||
**2. The console finds what exists by asking the bus,** one `$SRV.INFO` request, every answer
|
||||
gathered for a short window. What it announces through ADR 0195's five tools is what answered.
|
||||
|
||||
**3. What should exist is the mesh's records, read as data.** The controller answers its machines and
|
||||
modules as JSON, and says which modules declare tools; the console names as *not answering* only an
|
||||
assignment that declares tools and did not announce them. A module with no tools is never listed.
|
||||
|
||||
**4. The grants say so.** Every principal that serves tools may subscribe the services discovery
|
||||
subjects for what it serves; the console's and every runtime's account may publish the discovery
|
||||
request. Replies travel to the asker's own inbox as every reply does.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The standard `nats micro list` and `nats micro info` show the mesh's tools, live, to anybody holding
|
||||
a credential — the bus's own view, not the mesh's description of it.
|
||||
- Discovery costs one request and a gathering window, not one request per roster entry.
|
||||
- What got harder: three runtimes must answer the same format the same way — the Go tool runtime, the
|
||||
TypeScript runtime the containers still run, and the controller. The format is NATS's, so a test
|
||||
reads all three with the NATS services client and nothing of the mesh's.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A runtime announces exactly what it serves | each runtime's test: `$SRV.INFO` answered with one service per served module or seat, its endpoints' subjects the subjects served |
|
||||
| The format is NATS's | the same tests read the answer with the NATS services client's own types |
|
||||
| A module with no tools is never listed; an assignment with tools that did not answer is | the console's test, against controller records with both |
|
||||
| Nothing is parsed from prose | the console reads only JSON answers (code review; the text parsers are deleted) |
|
||||
| Live | `nats micro list` against the mesh's bus lists every machine's tool runtime and the controller |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0195](0195-the-meshs-tools-are-found-by-address-not-announced-whole.md),
|
||||
[ADR 0160](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md),
|
||||
[ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md)
|
||||
- [to-be 34](../03-DESIGN/01-to-be/34-the-console.md)
|
||||
+79
@@ -0,0 +1,79 @@
|
||||
---
|
||||
topic: what runs on it
|
||||
status: accepted
|
||||
date: 2026-10-03
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 02-DECISIONS/0193-every-bundle-the-runtime-serves-is-launched-and-the-runtime-knows-no-language.md
|
||||
---
|
||||
|
||||
# 198. A module's long-running code is launched by the node's runtime, and reaches the bus through it
|
||||
|
||||
## Context
|
||||
|
||||
[ADR 0193](0193-every-bundle-the-runtime-serves-is-launched-and-the-runtime-knows-no-language.md) made
|
||||
every tools bundle a child the node's runtime launches, speaking MCP over stdio, and gave the channel
|
||||
one bus verb: a tool's emit, published by the runtime as the module. Twenty-three modules still run the
|
||||
rest of their own code — event handlers, provisioners, a preparation step, three mains — in a container
|
||||
on the runtime's image, because that code needs what a container gave it: a bus connection that can
|
||||
*subscribe*, and its module's words. Research [022](../01-RESEARCH/022-where-a-modules-long-running-code-runs/00-overview.md)
|
||||
measured what it uses. [ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)
|
||||
§1 says a module's own code is never an image.
|
||||
|
||||
## Considered Options
|
||||
|
||||
1. **The runtime launches it and is its bus.** Chosen.
|
||||
2. A process per module with its own bus client and credential. Rejected for the reasons ADR 0188
|
||||
rejected it for tools: a transport in every language's SDK, a credential per module on disk, and a
|
||||
bus change rebuilding every module.
|
||||
3. Keep the containers for it. Rejected: ADR 0188's rule stays broken for most of the catalogue.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A module's long-running code is a bundle the node's runtime launches and supervises,** exactly as
|
||||
its tools are: an executable entrypoint, given the runtime's words and its module's
|
||||
([ADR 0192](0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md)),
|
||||
started at the runtime's start and again when it exits. A bundle may serve tools, run long, or both.
|
||||
|
||||
**2. The runtime is its bus.** The stdio channel carries, beside MCP, the mesh's verbs a module's code
|
||||
uses: `mesh/publish` (ADR 0193), **`mesh/subscribe`** — the runtime binds that module's durable
|
||||
consumer, as the module's own runtime did, and delivers each event to the child as a `mesh/event`
|
||||
request, acknowledging it on the bus only when the child has answered — and **`mesh/ask`**, a tool
|
||||
call made on the module's behalf. The runtime's account is granted what each module it carries
|
||||
consumes, and the consumer keeps the module's name, so no event is lost or replayed in the move.
|
||||
|
||||
**3. A preparation step is a run-once process the host runs before the runtime starts the module,**
|
||||
with its module's words and no bus — what it already was.
|
||||
|
||||
**4. What a container reached by its network is reached on the machine.** A service by its published
|
||||
port (`${port:…}`) on loopback; a backend's command-line client as a package of the machine's system,
|
||||
or, where the system has none, the backend's own driver inside the bundle.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The per-module containers go, and with them the runtime image as a way module code runs; ADR 0188's
|
||||
registration rule can then refuse a module's own image without exception.
|
||||
- One bus connection per machine carries every module's events; a module's handler is a function of
|
||||
the events it is handed, in any language, with no bus client of its own.
|
||||
- What got harder: the runtime holds every carried module's consumer and must not acknowledge an event
|
||||
before the child has handled it — a child that dies mid-event leaves it unacknowledged, and it is
|
||||
delivered again. The runtime's grants widen to what its modules consume.
|
||||
- Two modules need code before they can move: their backends' clients exist on no machine's system,
|
||||
so they talk to the backend through a driver instead.
|
||||
|
||||
## How it is checked
|
||||
|
||||
| Rule | Checked by |
|
||||
|---|---|
|
||||
| A subscribed event reaches the child and is acknowledged only after it answered | the runtime's test over a real bus: a child that answers is acknowledged once; one that dies mid-event is delivered again |
|
||||
| The module's consumer keeps its name | the composer's test: the durable consumer the runtime binds is the one the module's own runtime bound |
|
||||
| No module's own code is an image | the catalogue's registration check, without exception, once the last container has moved |
|
||||
| Live | every moved module's provisioner and handlers act, on their machines, from the node's runtime; `docker ps` shows no runtime-image container on any machine |
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md),
|
||||
[ADR 0192](0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md),
|
||||
[ADR 0193](0193-every-bundle-the-runtime-serves-is-launched-and-the-runtime-knows-no-language.md)
|
||||
- Research [022](../01-RESEARCH/022-where-a-modules-long-running-code-runs/00-overview.md)
|
||||
- [to-be 38](../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP4c
|
||||
+127
@@ -0,0 +1,127 @@
|
||||
---
|
||||
topic: the tiers
|
||||
status: accepted
|
||||
date: 2026-10-03
|
||||
deciders: jochen
|
||||
reconstructed: false
|
||||
extends: 0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md
|
||||
---
|
||||
|
||||
# 199. A module that answers names declares its zone, and a node's hosts file is one module's
|
||||
|
||||
## Context
|
||||
|
||||
**[ADR 0194](0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md) and
|
||||
[ADR 0196](0196-a-node-asks-the-meshs-resolver-first-and-a-public-one-only-when-it-is-silent.md) leave
|
||||
one resolver holding the nodes' internal domains, and retire the resolver every node ran.** Two kinds
|
||||
of names lived in those per-node resolvers that are neither a node nor a route, and both were found on
|
||||
the workstation on 2026-10-03:
|
||||
|
||||
- **Names a module answers.** The lab raises scenario machines and gives them addresses from its
|
||||
scenario files — the anchor's stand-in at a documentation address, the home server's on the LAN —
|
||||
and the workstation resolved `<machine>.incus` through two wildcard lines in a drop-in file its
|
||||
resolver read. The lines were written by hand; the addresses are the lab's, known only while a
|
||||
scenario runs.
|
||||
- **The operator's own names, unrelated to the mesh.** Twelve `<loopback> <name>` lines for a
|
||||
client's development hosts, kept in `/etc/hosts` and again in `/etc/hosts.local`, which the per-node
|
||||
resolver read as additional hosts.
|
||||
|
||||
**A manifest never names an address, a node or a domain** ([ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md)).
|
||||
So the lab cannot list `<machine>.incus → <address>` in its definition, and the operator's twelve lines
|
||||
are not any module's to define.
|
||||
|
||||
## Considered Options
|
||||
|
||||
**For a module's names:**
|
||||
|
||||
1. **The manifest lists its records.** Refused by ADR 0112: the addresses are the lab's runtime facts
|
||||
and the scenario's choice.
|
||||
2. **The module reports its records at runtime to the mesh's resolver**, which writes them into its
|
||||
configuration. It works, and it makes the resolver hold every module's runtime state and decide,
|
||||
per call, whether the caller may write the name it sent — authorisation for a write, on the one
|
||||
server every node depends on.
|
||||
3. **The module declares the zone it answers and the listen that answers it; the mesh's resolver
|
||||
forwards that zone there.** The definition names a zone (from a setting) and one of its own listens,
|
||||
which ADR 0112 allows; the address and the port are the mesh's facts. The records stay where they
|
||||
are known — in the module, at runtime. Chosen.
|
||||
|
||||
**For the operator's names:**
|
||||
|
||||
1. **Records the controller holds, served by the mesh's resolver.** They are not the mesh's: a client's
|
||||
development hosts on one machine are nothing any other node should resolve, and the controller would
|
||||
become the keeper of a workstation's private notes.
|
||||
2. **A node-scoped module owns `/etc/hosts`, and the operator's lines live in its kept region**
|
||||
([ADR 0174](0174-a-node-varies-a-module-through-settings-and-kept-regions-never-an-edit.md)), changed
|
||||
through that module's tools on that machine. Chosen.
|
||||
|
||||
## Decision
|
||||
|
||||
**1. A module that answers names declares a zone.** Its definition names the zone — a single label or a
|
||||
dotted name, from a setting, never a domain the mesh knows — and the listen that answers DNS for it.
|
||||
The controller refuses two modules in the mesh declaring one zone, and a zone that is the mesh's suffix,
|
||||
under it, or one of a node's public domains: a module may not shadow names the mesh or the public DNS
|
||||
answers.
|
||||
|
||||
**2. The mesh's resolver forwards each zone to the module that declared it.** The controller hands the
|
||||
holder of `mesh-dns-resolver` every declared zone with the private address of the node its module runs
|
||||
on and the port that listen is published on; the holder places one forwarding rule per zone into its
|
||||
configuration and answers nothing in that zone itself. What names exist in the zone, and their
|
||||
addresses, are the module's — answered by its own long-running code
|
||||
([ADR 0198](0198-a-modules-long-running-code-is-launched-by-the-node-runtime-and-reaches-the-bus-through-it.md)),
|
||||
from its own state, as they change. Whether an answered address is reachable from the asking node is
|
||||
the module's matter, not the resolver's.
|
||||
|
||||
**3. A node's `/etc/hosts` is held by one module, through a node seat, `node-hosts-file`.** The seat is
|
||||
the definition: its holder owns `/etc/hosts`, and implements three verbs — MCP tool definitions served
|
||||
as `<node>/node-hosts-file.<verb>` ([ADR 0195](0195-the-meshs-tools-are-found-by-address-not-announced-whole.md)):
|
||||
**`entries`** (the file's lines, the module's and the operator's, each marked whose), **`add`** (one
|
||||
address and its names, into the operator's region) and **`remove`** (one name or address from it). The
|
||||
module writes the machine's own lines — loopback and the machine's name — and keeps a region for the
|
||||
operator, which survives every push and is given back when the module goes. Its tools change that
|
||||
region on that machine, escalating as the packet filter's do
|
||||
([ADR 0175](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md) §4). **The
|
||||
controller holds none of it:** an operator's line is the machine's, not a record.
|
||||
|
||||
**4. No other module writes `/etc/hosts`.** The private network's region goes, as ADR 0194 already has
|
||||
it; a module that once wrote a line there asks the mesh's resolver instead.
|
||||
|
||||
## Consequences
|
||||
|
||||
- **The lab's names follow its scenarios.** A scenario raised is resolvable from every node at once; a
|
||||
scenario torn down is gone, with no line left behind in any file.
|
||||
- **The mesh's resolver holds no module's state.** It holds the nodes' domains and a table of who
|
||||
answers which zone, both composed by the controller; nothing writes to it at runtime.
|
||||
- **A module answering a zone needs a DNS answerer of its own** — a long-running bundle, or a resolver
|
||||
it runs. The lab gains one.
|
||||
- **The operator's names reach the machine's own programs, not its containers.** A container does not
|
||||
read the machine's `/etc/hosts`. For names unrelated to the mesh that is the right boundary; a name a
|
||||
container needs belongs in a zone.
|
||||
- **Taking `/etc/hosts` keeps what is there.** The first time the module writes the file, every line
|
||||
that is not the machine's own goes into the operator's region, so a workstation's twelve lines survive
|
||||
the take — the same adoption [ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md) gives
|
||||
every shared file.
|
||||
|
||||
**How each is checked:**
|
||||
|
||||
- **Zones:** the controller's catalogue tests refuse a second module declaring a zone, a zone under the
|
||||
mesh suffix, and a zone equal to a node's public domain.
|
||||
- **Forwarding:** on the holder, the resolver's configuration carries one forwarding rule per declared
|
||||
zone, at the declaring node's private address and published port; asking any node's resolver for a
|
||||
name in the lab's zone while a scenario runs returns the scenario's address.
|
||||
- **The hosts file:** a push leaves the operator's region byte for byte; `add` followed by `entries`
|
||||
shows the line as the operator's; unassigning the module gives the region back.
|
||||
|
||||
## References
|
||||
|
||||
- [ADR 0194](0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md),
|
||||
[ADR 0196](0196-a-node-asks-the-meshs-resolver-first-and-a-public-one-only-when-it-is-silent.md) —
|
||||
the one resolver and how nodes ask it.
|
||||
- [ADR 0112](0112-a-module-definition-names-no-node-mesh-or-path.md) — why a definition names no address.
|
||||
- [ADR 0174](0174-a-node-varies-a-module-through-settings-and-kept-regions-never-an-edit.md),
|
||||
[ADR 0102](0102-the-mesh-writes-into-a-shared-file-never-over-it.md) — kept regions and shared files.
|
||||
- [ADR 0198](0198-a-modules-long-running-code-is-launched-by-the-node-runtime-and-reaches-the-bus-through-it.md) —
|
||||
where a zone's answerer runs.
|
||||
- [Connectivity §2](../03-DESIGN/01-to-be/08-connectivity.md) and [the seats](../03-DESIGN/01-to-be/26-the-seats.md),
|
||||
amended alongside.
|
||||
- [Research 023](../01-RESEARCH/023-a-seat-protocol-that-defines-what-its-holder-owns/00-overview.md) —
|
||||
the general form of decision 3's "the holder owns `/etc/hosts`".
|
||||
+95
-6
@@ -48,6 +48,31 @@ form above and dated no earlier than the record's own `date:` — an unmarked ed
|
||||
violation the reviewer looks for in the diff, and a marked one is legible in the record itself.
|
||||
The git history is the backstop, not the record of intent; the note is the record of intent.
|
||||
|
||||
## A pointer back from what a record changes
|
||||
|
||||
A new record naming an old one is not enough. **Where a record changes a mechanism an older record
|
||||
states — without reversing the decision, so no supersession — the older record gets a dated note
|
||||
saying where its mechanism now lives.** A reader arrives at the old record by following a citation,
|
||||
and finds text that is still the decision and no longer the method; nothing in it says a later record
|
||||
moved the method, and the new record is not in their hands.
|
||||
|
||||
> **The mechanism changed — YYYY-MM-DD, by ADR NNNN.** What still stands, what moved,
|
||||
> and why.
|
||||
|
||||
Three examples of the shape, all found by being missed: ADR 0066 still described a routed name being
|
||||
written into every container after 0148 replaced that with resolution; ADR 0047 still said a module's
|
||||
code runs in a container after 0150 made it a supervised process; and ADR 0016 still read as though the
|
||||
lab were the test bed after 0149 said the live mesh is. Each was a citation leading to the wrong
|
||||
answer, in a record that was not wrong about anything it decided.
|
||||
|
||||
**This is not machine-checked, and it cannot be from `extends:` alone.** 102 records extend another and
|
||||
87 name a parent that does not mention them, which is correct: extending usually means building on a
|
||||
context, and a one-directional pointer is the right shape for that. What needs a note is the narrower
|
||||
case where the parent's own text has gone stale, and which case that is, is a judgement — so it is a
|
||||
rule for the author and the reviewer, and the diff is where it is caught. Making it mechanical would
|
||||
mean a record declaring the relationship in its frontmatter, which is a change to the record schema and
|
||||
has not been decided.
|
||||
|
||||
The records run in the order the decisions were taken, oldest first.
|
||||
|
||||
**Every decision is a record.** There is no ledger and no index file — if a decision is worth
|
||||
@@ -141,6 +166,29 @@ python3 00-META/checks/index.py fail if stale
|
||||
- **0130** — [The predecessor is ending, and its broker goes with it](0130-the-predecessor-is-ending-and-its-broker-goes-with-it.md)
|
||||
- **0131** — [Everything on the mesh speaks to the broker seat, and AMQP is not a provision](0131-everything-on-the-mesh-speaks-to-the-broker-seat.md)
|
||||
- **0132** — [A seat carries the tools its holder must serve](0132-a-seat-carries-the-tools-its-holder-must-serve.md)
|
||||
- **0134** — [The mesh says what it applied](0134-the-mesh-says-what-it-applied.md)
|
||||
- **0142** — [The mesh delivers its own components as binaries, not as container images](0142-the-mesh-delivers-its-own-components-as-binaries.md)
|
||||
- **0154** — [The mesh's own verbs are the mesh-controller seat's tools, and which verbs those are](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md)
|
||||
- **0156** — [An artifact is what a build produces, the artifact store serves every kind, and its seat is named for its scope](0156-an-artifact-is-what-a-build-produces-and-the-store-is-named-for-its-scope.md)
|
||||
- **0157** — [A build says what it does on the bus, as it happens](0157-a-build-says-what-it-does-on-the-bus-as-it-happens.md)
|
||||
- **0158** — [A provider with one credential shares it with every consumer, and the vault remakes it for all of them at once](0158-a-provider-with-one-credential-shares-it-with-every-consumer.md)
|
||||
- **0159** — [A tool call names the machine it is for, every answer says which machine answered, and a holder's runtime serves its seat's verbs](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md)
|
||||
- **0160** — [The mesh issues an assignment's subjects, and a runtime serves what it is issued](0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md)
|
||||
- **0161** — [What deserves a seat: a role of a module is a seat, a singular fact about machines is a placement with a capacity of one, and a holder's software is the machine's](0161-what-deserves-a-seat.md)
|
||||
- **0162** — [A merge produces a tiered plan the mesh keeps, and a module's dependencies are one relation in the catalogue](0162-a-merge-produces-a-tiered-plan-the-mesh-keeps.md)
|
||||
- **0163** — [Taking a module over is a comparison: what it compares, what it refuses, and what it carries](0163-taking-a-module-over-is-a-comparison.md)
|
||||
- **0167** — [A membership carries what its module receives, and who the mesh is](0167-a-membership-carries-what-its-module-receives-and-who-the-mesh-is.md)
|
||||
- **0168** — [A converged machine is filtered by the mesh alone, and the host says what else refuses](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md)
|
||||
- **0169** — [A machine joins through the tunnel, and the bus is never public](0169-a-machine-joins-through-the-tunnel-and-the-bus-is-never-public.md)
|
||||
- **0170** — [The firewall seat serves its verbs, and a foreign rule set is removed through one of them](0170-the-firewall-seat-serves-its-verbs.md)
|
||||
- **0172** — [The lab is a module, and runs a bed when the mesh asks](0172-the-lab-is-a-module-and-runs-a-bed-when-the-mesh-asks.md)
|
||||
- **0179** — [The intrusion seat serves its verbs, a container may log to the journal, and every door declares its jail](0179-the-intrusion-seat-serves-its-verbs-and-every-door-declares-its-jail.md)
|
||||
- **0180** — [The found front end is uninstalled once a machine is converged](0180-the-found-front-end-is-uninstalled-once-a-machine-is-converged.md)
|
||||
- **0184** — [A service the mesh asked to run is still running a moment later](0184-a-service-the-mesh-asked-to-run-is-still-running-a-moment-later.md)
|
||||
- **0185** — [A control plane behind its seat's row serves what it can](0185-a-control-plane-behind-its-seats-row-serves-what-it-can.md)
|
||||
- **0186** — [A ban list never holds a neighbour, and the mesh's own bans are its own wherever they hang](0186-a-ban-list-never-holds-a-neighbour.md)
|
||||
- **0187** — [A dead tracker is not the machine's failure](0187-a-dead-tracker-is-not-the-machines-failure.md)
|
||||
- **0190** — [A seat's work is shared by its holders, and building is the first such role](0190-a-seats-work-is-shared-by-its-holders-and-building-is-the-first-such-role.md)
|
||||
|
||||
### Its tiers, from the bottom up
|
||||
|
||||
@@ -172,6 +220,12 @@ python3 00-META/checks/index.py fail if stale
|
||||
- **0108** — [A route carries the policy applied to a request, and names a secret rather than holding one](0108-a-route-carries-the-policy-applied-to-a-request.md)
|
||||
- **0109** — [A package registry seat is one per ecosystem, not one for all of them](0109-a-package-registry-seat-is-one-per-ecosystem.md)
|
||||
- **0126** — [A module declares its own seats; the mesh reserves its own](0126-a-module-declares-its-own-seats.md)
|
||||
- **0148** — [The mesh's names are resolved, not copied into every container](0148-the-meshs-names-are-resolved-not-copied-into-containers.md)
|
||||
- **0151** — [A route's internal name is composed under the node that serves it](0151-a-routes-internal-name-is-composed-under-the-node-that-serves-it.md)
|
||||
- **0191** — [The mesh's resolver holds only the mesh's own names; a public name resolves publicly](0191-the-meshs-resolver-holds-only-the-meshs-own-names.md)
|
||||
- **0194** — [The mesh has one resolver, and every node asks it for the mesh's names](0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md)
|
||||
- **0196** — [A node asks the mesh's resolver first, and a public one only when it is silent](0196-a-node-asks-the-meshs-resolver-first-and-a-public-one-only-when-it-is-silent.md)
|
||||
- **0199** — [A module that answers names declares its zone, and a node's hosts file is one module's](0199-a-module-that-answers-names-declares-its-zone-and-a-nodes-hosts-file-is-one-modules.md)
|
||||
|
||||
### What runs on them, and how it gets there
|
||||
|
||||
@@ -204,15 +258,47 @@ python3 00-META/checks/index.py fail if stale
|
||||
- **0091** — [A mount is declared, and there are three things it can be](0091-a-mount-is-declared-three-ways.md)
|
||||
- **0099** — [A step that runs once names what it reads, and runs again when it changed](0099-a-step-that-runs-once-names-what-it-reads.md)
|
||||
- **0110** — [A seat is held by one assignment, from a closed set, and it may deliver a provision](0110-a-seat-is-a-module-assignment-from-a-closed-set.md)
|
||||
- **0112** — [A module definition names no node, no mesh and no path: everything it needs is a requirement the mesh resolves](0112-a-module-definition-names-no-node-mesh-or-path.md) *(proposed)*
|
||||
- **0113** — [The vault makes every shared secret, a provider makes resources and data, and the mesh carries both](0113-the-vault-makes-every-secret.md) *(proposed)*
|
||||
- **0114** — [A credential two parties hold rotates over two credentials; one a single party holds rotates in place, staged; and retiring a credential never removes what it reached](0114-a-shared-credential-rotates-over-two-credentials.md) *(proposed)*
|
||||
- **0115** — [One assignment of a module per node: the module's name is the assignment's identity](0115-one-assignment-of-a-module-per-node.md) *(proposed)*
|
||||
- **0112** — [A module definition names no node, no mesh and no path: everything it needs is a requirement the mesh resolves](0112-a-module-definition-names-no-node-mesh-or-path.md)
|
||||
- **0113** — [The vault makes every shared secret, a provider makes resources and data, and the mesh carries both](0113-the-vault-makes-every-secret.md)
|
||||
- **0114** — [A credential two parties hold rotates over two credentials; one a single party holds rotates in place, staged; and retiring a credential never removes what it reached](0114-a-shared-credential-rotates-over-two-credentials.md)
|
||||
- **0115** — [One assignment of a module per node: the module's name is the assignment's identity](0115-one-assignment-of-a-module-per-node.md)
|
||||
- **0117** — [A machine's uplink is a seat: the mesh configures the manager, never the link](0117-a-machines-uplink-is-a-seat.md)
|
||||
- **0118** — [Undeclaring removes what the mesh made, and gives a unit back the state it was found in](0118-undeclaring-gives-a-unit-back-the-state-it-was-found-in.md)
|
||||
- **0120** — [A roster fact carries its format as a template: the mesh owns the data, the module owns the format](0120-a-roster-fact-carries-its-format-as-a-template.md)
|
||||
- **0121** — [A system seat is named for its scope, and a module may define its own](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md)
|
||||
- **0122** — [A seat is data the controller owns, and a rename is a database update](0122-a-seat-is-data-a-rename-is-a-database-update.md)
|
||||
- **0133** — [A module owns its migrations, and the mesh owns when they run](0133-a-module-owns-its-migrations-and-the-mesh-owns-when-they-run.md) *(superseded)*
|
||||
- **0135** — [A module version prepares its state before it runs](0135-a-module-version-prepares-its-state-before-it-runs.md)
|
||||
- **0136** — [A step gates its module, not the machine](0136-a-step-gates-its-module-not-the-machine.md)
|
||||
- **0137** — [A machine says which networks it routes](0137-a-machine-says-which-networks-it-routes.md) *(superseded)*
|
||||
- **0138** — [An assignment binds an endpoint and says how far it reaches](0138-an-assignment-binds-an-endpoint-and-says-how-far-it-reaches.md)
|
||||
- **0139** — [A network is forwarded because a module declared it](0139-a-network-is-forwarded-because-a-module-declared-it.md) *(superseded)*
|
||||
- **0140** — [The filter constrains what arrives from outside, and says nothing about a machine's own guests](0140-the-filter-constrains-what-arrives-from-outside.md)
|
||||
- **0141** — [The host delivers its own successor, and versions live side by side](0141-the-host-delivers-its-own-successor.md)
|
||||
- **0143** — [A consumer verifies the grant it is given](0143-a-consumer-verifies-the-grant-it-is-given.md) *(superseded)*
|
||||
- **0144** — [Anything on a machine may call anything on it, and that is the whole of "local"](0144-anything-on-a-machine-may-call-anything-on-it.md)
|
||||
- **0145** — [A module checks what the mesh claims is reachable, and it checks itself](0145-a-module-checks-what-the-mesh-claims-is-reachable.md) *(superseded)*
|
||||
- **0146** — [Connectivity is checked by name, per hosting form, with a valid certificate](0146-connectivity-is-checked-by-name-per-hosting-form.md)
|
||||
- **0147** — [A module anchors the mesh's authority on a machine, and takes it away again](0147-a-module-anchors-the-meshs-authority.md)
|
||||
- **0150** — [A module's own code runs as supervised processes under the module's one account](0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md)
|
||||
- **0152** — [The operator's surface is a module the mesh assigns: the console](0152-the-operators-surface-is-a-module-the-console.md)
|
||||
- **0155** — [A definition names no installation: how that is checked, and the three ways a value that did gets out](0155-a-definition-names-no-installation-and-how-that-is-checked.md)
|
||||
- **0164** — [A setting is declared with its default, its meaning and what changing it costs](0164-a-setting-is-declared-with-its-default-its-meaning-and-what-changing-it-costs.md) *(proposed)*
|
||||
- **0165** — [`container-runtime` is what a machine can run; that a runtime is running is its holder's health](0165-container-runtime-is-what-a-machine-can-run-and-a-running-runtime-is-its-holders-health.md) *(proposed)*
|
||||
- **0166** — [The container runtime is a node seat, and the host creates containers through its holder](0166-the-container-runtime-is-a-node-seat-and-the-host-creates-containers-through-its-holder.md) *(proposed)*
|
||||
- **0173** — [The operator's machine is the mesh's, and a module is whatever it declares](0173-the-operators-machine-is-the-meshs-and-a-module-is-what-it-declares.md)
|
||||
- **0175** — [One tool runtime per node serves every module's tools, on the host side](0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md)
|
||||
- **0176** — [The login shell is a node seat held by one shell module, and `execute` is its contract](0176-the-login-shell-is-a-node-seat-and-execute-is-its-contract.md)
|
||||
- **0177** — [A unit may be user-scoped, and the service manager is a node seat whose holder answers for the units](0177-a-unit-may-be-user-scoped-and-the-service-manager-is-a-node-seat.md)
|
||||
- **0181** — [The operator account is a node fact, and a home is a placement root](0181-the-operator-account-is-a-node-fact-and-a-home-is-a-placement-root.md)
|
||||
- **0182** — [Inside a home, the mesh owns the directory and the files it places, writes into the tool's own files, and holds everything else as found](0182-inside-a-home-the-mesh-owns-what-it-places-and-holds-the-rest-as-found.md)
|
||||
- **0183** — [The Anthropic licence manager is a module holding a seat; it hands each node's agent its token over the bus, sealed; the controller and the host have no part](0183-the-anthropic-licence-manager-is-a-module-and-hands-tokens-to-the-agent-over-the-bus.md)
|
||||
- **0188** — [A module's own code is bundles in any language, and a tools bundle speaks MCP to the runtime](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)
|
||||
- **0192** — [A tools bundle declares what it is given, and the runtime hands it to that bundle alone](0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md)
|
||||
- **0193** — [Every bundle the runtime serves is launched, and the runtime knows no language](0193-every-bundle-the-runtime-serves-is-launched-and-the-runtime-knows-no-language.md)
|
||||
- **0195** — [The mesh's tools are found by address, not announced whole](0195-the-meshs-tools-are-found-by-address-not-announced-whole.md)
|
||||
- **0197** — [Every tool announces itself on the bus, in the NATS services protocol](0197-every-tool-announces-itself-on-the-bus-in-the-nats-services-protocol.md)
|
||||
- **0198** — [A module's long-running code is launched by the node's runtime, and reaches the bus through it](0198-a-modules-long-running-code-is-launched-by-the-node-runtime-and-reaches-the-bus-through-it.md)
|
||||
|
||||
### How it is built
|
||||
|
||||
@@ -222,9 +308,9 @@ python3 00-META/checks/index.py fail if stale
|
||||
- **0014** — [No workspace — each module is a standalone package consuming published dependencies](0014-no-npm-workspace.md)
|
||||
- **0015** — [Applications live in their own repository; the monorepo is for the mesh](0015-applications-live-in-their-own-repository.md)
|
||||
- **0016** — [The lab](0016-the-lab.md)
|
||||
- **0037** — [Where a module lives](0037-where-a-module-lives.md) *(proposed)*
|
||||
- **0037** — [Where a module lives](0037-where-a-module-lives.md)
|
||||
- **0039** — [What the SDK holds, and what it refuses](0039-what-the-sdk-holds-and-refuses.md)
|
||||
- **0068** — [The lab takes requests, one at a time, and runs each from its own copy](0068-the-lab-takes-requests.md) *(proposed)*
|
||||
- **0068** — [The lab takes requests, one at a time, and runs each from its own copy](0068-the-lab-takes-requests.md) *(superseded)*
|
||||
- **0069** — [A module is a repository and a path within it](0069-a-module-is-a-repository-and-a-path.md)
|
||||
- **0076** — [The SDK is a published package, and the toolchain resolves it by version](0076-the-sdk-is-a-published-package.md)
|
||||
- **0082** — [The registry is reached by name, and the overlay is its security](0082-the-registry-is-reached-by-name-and-trusted-by-the-overlay.md)
|
||||
@@ -233,6 +319,8 @@ python3 00-META/checks/index.py fail if stale
|
||||
- **0097** — [A vendor image is a declared build input, and a recipe fetches nothing undeclared](0097-a-vendor-image-is-a-declared-build-input.md)
|
||||
- **0107** — [Persistent data is a directory bind, never a named volume](0107-persistent-data-is-a-directory-bind-never-a-named-volume.md)
|
||||
- **0111** — [A build source is on the mesh's git seat, or it is an external repository](0111-a-build-source-is-on-the-git-seat-or-external.md)
|
||||
- **0149** — [The live mesh is the test bed](0149-the-live-mesh-is-the-test-bed.md)
|
||||
- **0174** — [A node varies a module through settings and kept regions, never through an edit](0174-a-node-varies-a-module-through-settings-and-kept-regions-never-an-edit.md)
|
||||
|
||||
### How it is checked
|
||||
|
||||
@@ -253,5 +341,6 @@ python3 00-META/checks/index.py fail if stale
|
||||
- **0034** — [The local account owns the mesh, and a web application's login is not that](0034-the-local-account-owns-the-mesh.md)
|
||||
- **0080** — [The development cycle is checked, not trusted](0080-the-development-cycle-is-checked.md)
|
||||
- **0081** — [A decision nothing cites is not yet in the chain](0081-a-decision-nothing-cites-is-not-yet-in-the-chain.md)
|
||||
- **0153** — [The record is read by a module the mesh assigns, and the console lists it](0153-the-record-is-read-by-a-module-and-the-console-lists-it.md)
|
||||
|
||||
<!-- index:end -->
|
||||
|
||||
@@ -1,78 +1,58 @@
|
||||
---
|
||||
layer: as-is
|
||||
status: implemented
|
||||
code: [hal]
|
||||
updated: 2026-08-23
|
||||
decisions: []
|
||||
code: [mesh-catalog modules/records, mesh-catalog modules/mesh-console]
|
||||
updated: 2026-09-30
|
||||
decisions:
|
||||
- 02-DECISIONS/0025-the-design-record-is-read-not-copied.md
|
||||
- 02-DECISIONS/0153-the-record-is-read-by-a-module-and-the-console-lists-it.md
|
||||
- 02-DECISIONS/0152-the-operators-surface-is-a-module-the-console.md
|
||||
---
|
||||
|
||||
# Knowledge
|
||||
|
||||
The mesh keeps two knowledge stores. They are not redundant, and knowing which is which is the
|
||||
difference between finding an answer in one search and rediscovering it over several hours.
|
||||
**The mesh keeps no knowledge store.** What it knows is what its modules answer, and the way a person
|
||||
or an agent asks is the console's tool list on the machine they sit at
|
||||
([13 — The console](13-the-console.md)). This document used to describe two stores; it is rewritten
|
||||
because neither exists from the mesh's side, and an as-is document that describes what is gone is a
|
||||
brochure.
|
||||
|
||||
## The operational memory
|
||||
## What was here, and where it went
|
||||
|
||||
A store of operational notes, written and read by whoever — human or agent — is working. Each
|
||||
note is a slug and a body: how something works, what went wrong, what the fix was, what
|
||||
assumption turned out to be false.
|
||||
Until the cut-over of 2026-09-28 the predecessor ran two stores: an operational memory of notes
|
||||
indexed on symptoms, and a structured archive of governed documents with a librarian approving
|
||||
promotion. Both were reached through the predecessor's tool server over the bus the mesh removed
|
||||
([issue 147](../../04-ISSUES/147-the-operators-tools-still-dial-the-bus-that-was-removed/00-report.md)).
|
||||
Nothing in the mesh reaches them now, and nothing in the mesh has replaced them: there is no note
|
||||
store, no archive, no librarian, and the lessons of the last days were written into this repository by
|
||||
hand. That is a gap, and it is stated here rather than papered over. What replaces a symptom-indexed
|
||||
memory, if anything does, is undecided.
|
||||
|
||||
It is indexed on **symptoms**. The entry someone needs is usually titled after the error they
|
||||
are staring at, which is why the standing instruction is to search the literal error text
|
||||
before forming a hypothesis rather than after one fails.
|
||||
## The record
|
||||
|
||||
Its content is overwhelmingly the record of previous debugging: a large body of
|
||||
troubleshooting entries, module conventions, and standing notes about work that is open. It is
|
||||
the mesh's institutional memory of *what has already gone wrong*.
|
||||
**The design record is read where it is written.** Since 2026-09-30 a module, `records`, keeps a
|
||||
checkout of this repository from the forge — cloned from the `git` seat, reset to the origin on every
|
||||
merge the forge announces and every ten minutes — and answers over the bus: where a phrase appears as
|
||||
written, one document whole, what a folder holds, and where the checkout stands, each naming the
|
||||
commit it read. Which repository it reads is a setting on its assignment; the module names no mesh.
|
||||
|
||||
The cost of skipping it is documented in the mesh's own record: entries have been rediscovered
|
||||
from scratch, over hours, in sessions where the search was skipped because the trail felt
|
||||
confident. It fires hardest on familiar ground, not unfamiliar ground.
|
||||
It is listed by the console beside every other tool, with a description that says to search the
|
||||
literal words of a symptom before forming a hypothesis. That is what
|
||||
[ADR 0025](../../02-DECISIONS/0025-the-design-record-is-read-not-copied.md) meant by *beside
|
||||
everything else*, in a mesh with no store to be beside
|
||||
([ADR 0153](../../02-DECISIONS/0153-the-record-is-read-by-a-module-and-the-console-lists-it.md)).
|
||||
|
||||
## The structured archive
|
||||
Nothing is copied. A checkout lags the source by seconds after an announced merge and by minutes
|
||||
otherwise, and says so.
|
||||
|
||||
A second store, structured rather than flat: spaces, pages, revisions, tiers, and full-text
|
||||
search. Where the operational memory is a note, this is a document with an owner and a
|
||||
lifecycle.
|
||||
## The constitution
|
||||
|
||||
Content is promoted through tiers — private, then team, then platform — with a librarian agent
|
||||
owning approval and promotion at the boundary. Proposals to edit are reviewed rather than
|
||||
applied.
|
||||
|
||||
This is where the mesh's **governed** documents live, including the constitution injected into
|
||||
design sessions ([ADR 0020](../../02-DECISIONS/0020-the-mesh-is-governed-by-a-constitution.md)).
|
||||
|
||||
## Why both
|
||||
|
||||
The distinction is by lifecycle, not by subject.
|
||||
|
||||
| Operational memory | Structured archive |
|
||||
|---|---|
|
||||
| Written the moment something is learned | Written deliberately, reviewed |
|
||||
| Flat, symptom-indexed | Structured, tiered, owned |
|
||||
| Anyone writes; nothing approves | Promotion is approved |
|
||||
| Truth is "this happened" | Truth is "this is agreed" |
|
||||
|
||||
Collapsing them would cost one of the two properties: either every hard-won note waits for
|
||||
review, or governed documents can be changed by anyone mid-incident.
|
||||
[`00-META/how-we-build.md`](../../00-META/how-we-build.md) is the source of the mesh constitution
|
||||
([ADR 0021](../../02-DECISIONS/0021-hq-is-the-source-of-the-constitution.md)). The page it used to be
|
||||
synchronised into lived in the predecessor's archive and is unreachable; the constitution today is
|
||||
read from this repository, through the same module, and playbook 05's sync has nothing to write to.
|
||||
|
||||
## Where this repository sits
|
||||
|
||||
This repository is a third thing, and the objection was raised when it was created: a fourth
|
||||
knowledge system repeats the mistake the split was made to fix.
|
||||
|
||||
The answer given was **indexing, not location** — that these documents are indexed into the
|
||||
knowledge base so that a symptom search returns them alongside everything else. One source,
|
||||
many surfaces.
|
||||
|
||||
**That indexing does not currently exist.** A search for this repository's content returns
|
||||
nothing. The claim is load-bearing for the decision to separate the repository at all, and
|
||||
until it is true, this repository is exactly the fourth knowledge system the objection
|
||||
described. Recorded here because it is a statement about how the mesh's knowledge actually
|
||||
works today, and as [`04-ISSUES/006`](../../04-ISSUES/006-hq-is-not-indexed-into-the-knowledge-base/00-report.md).
|
||||
|
||||
## The librarian
|
||||
|
||||
A single agent owns the archive's approvals and promotions. Its approval capabilities have at
|
||||
times not been reachable as tools, which does not affect the operational memory but does mean
|
||||
promotion stops silently — the store keeps accepting proposals that nothing can approve.
|
||||
A third thing beside two that are gone, which makes it the first: the one governed record the mesh
|
||||
has, public, read by a module the mesh assigns, and edited nowhere else.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user