Issues 119 and 122: what a host path is, and what a node's layout would replace #130

2026-09-26T15:21:28Z

jschoubben commented

2026-09-26 15:21:28 +00:00

Documentation only — nothing in the catalogue is touched, deliberately.

Not every host path names this machine. Recounted by what the path is:

What the path is	Count	Names this installation?
A module's own data, `/var/lib/<module>/…`	289	Yes
What the mesh writes for a module, `/var/lib/mesh/<module>/…`	225	Yes
The operator's shared data, `/services/…`	166	Already answered — an `access`, ADR 0051; where belongs on the assignment
A system file the mesh owns, `/etc/…` and a few under `/var/`	18	No — the path is the fact, identical on every machine of the kind
A path inside a container	236	No — the software's own contract

So the category a node's default layout would replace is 514, not 789 and not 698.

The reservation model is already recorded, and it is what one would expect: ADR 0112 makes a directory a host provision whose contract is the owner and mode, with where it lands being the assignment's; to-be 27 resolves that as a root per node with one directory per assignment beneath it, plus a placement for a directory that must sit elsewhere, such as where an adopted machine's data already is. Both are proposed.

Three things nothing states, written into 119 so they are not rediscovered: where the root comes from (a node setting fixed at installation, and what a node that states none falls back to); what sits beneath it — the catalogue keeps two subtrees per module today, its data and what the mesh writes for it, so this decides whether an assignment's directory holds both; and the order the 514 are retired in, which 0112 also leaves open.

And why the report stops at documenting. Changing where a definition looks, without the data moving with it, does not fail loudly: the mesh creates the new directory with the right owner and mode, the container starts, and the service comes up empty. The loudest case here holds 174.9 GiB; a mail spool and the mesh's own store are the same shape. Retiring these paths is a data migration with a verification step, module by module — not a manifest edit — and the planning belongs with whoever can see the machine.

Checks: cycle 288 documents, the chain holds; records 104, all passed; index current.

Documentation only — nothing in the catalogue is touched, deliberately. **Not every host path names this machine.** Recounted by what the path *is*: | What the path is | Count | Names this installation? | |---|---|---| | A module's own data, `/var/lib/<module>/…` | 289 | **Yes** | | What the mesh writes for a module, `/var/lib/mesh/<module>/…` | 225 | **Yes** | | The operator's shared data, `/services/…` | 166 | Already answered — an `access`, ADR 0051; *where* belongs on the assignment | | A system file the mesh owns, `/etc/…` and a few under `/var/` | 18 | **No** — the path is the fact, identical on every machine of the kind | | A path inside a container | 236 | **No** — the software's own contract | So the category a node's default layout would replace is **514**, not 789 and not 698. **The reservation model is already recorded**, and it is what one would expect: ADR 0112 makes a directory a host provision whose contract is the owner and mode, with where it lands being the assignment's; to-be 27 resolves that as *a root per node with one directory per assignment beneath it*, plus a placement for a directory that must sit elsewhere, such as where an adopted machine's data already is. Both are `proposed`. **Three things nothing states**, written into 119 so they are not rediscovered: where the root comes from (a node setting fixed at installation, and what a node that states none falls back to); what sits beneath it — the catalogue keeps two subtrees per module today, its data and what the mesh writes for it, so this decides whether an assignment's directory holds both; and the order the 514 are retired in, which 0112 also leaves open. **And why the report stops at documenting.** Changing where a definition looks, without the data moving with it, does not fail loudly: the mesh creates the new directory with the right owner and mode, the container starts, and the service comes up **empty**. The loudest case here holds 174.9 GiB; a mail spool and the mesh's own store are the same shape. Retiring these paths is a data migration with a verification step, module by module — not a manifest edit — and the planning belongs with whoever can see the machine. Checks: cycle 288 documents, the chain holds; records 104, all passed; index current.

jschoubben added 1 commit 2026-09-26 15:21:28 +00:00

Issues 119 and 122: what a host path is, and what a node's layout would replace f709e8e0fb

Not every host path names this machine. A system file the mesh owns is at that path on every machine
of the kind — the path is the fact. The operator's shared data is already answered as an access. A
path inside a container is the software's contract. What is left, and what a node's default layout
would replace, is 514: a module's own data, and what the mesh writes for that module.

Documents the reservation model as the records already have it — a root per node, one directory per
assignment, a placement for adopted data — and the three things nothing states: where the root comes
from, what sits beneath it, and the order the 514 are retired in.

Stops there deliberately. Changing where a definition looks without moving the data does not fail: the
mesh creates the directory, the container starts, the service comes up empty. Retiring these is a data
migration with a verification step, module by module, and belongs with whoever can see the machine.

jschoubben merged commit 782d5ace04 into main

2026-09-26 15:21:35 +00:00

jschoubben deleted branch issue/119-122-what-a-host-path-is

2026-09-26 15:21:35 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#130