From 1e1957a9c49615d36d7c15bea8f4d72286326075 Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 30 Sep 2026 21:11:42 +0200 Subject: [PATCH] Issue 119 resolved for a module's own data; issue 174 for the mesh's files; design 27 phase 3 in part --- .../27-a-module-requires-the-mesh-resolves.md | 7 +++ .../00-report.md | 33 +++++++++++-- .../00-report.md | 48 +++++++++++++++++++ 3 files changed, 85 insertions(+), 3 deletions(-) create mode 100644 04-ISSUES/174-the-meshs-own-files-for-a-module-are-placed-by-the-definition/00-report.md diff --git a/03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md b/03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md index 8ac3cde..b124d11 100644 --- a/03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md +++ b/03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md @@ -181,6 +181,13 @@ first form is [`${dir:}`](../../04-ISSUES/119-a-module-definition-decides-wh a placed directory under the node's root. Each is this design's provider in the shape the existing placeholders have, not yet the one requirement form below; they are phase 1's first cases. +*Phase 3, in part (2026-09-30):* every definition's **own** data directory is placed; the conversion +moved no data, proven by resolving both catalogues with the controller's rule and comparing +([issue 119](../../04-ISSUES/119-a-module-definition-decides-where-its-files-live/00-report.md)). +What the mesh writes *for* a module is still placed by the definition +([issue 174](../../04-ISSUES/174-the-meshs-own-files-for-a-module-are-placed-by-the-definition/00-report.md)), +which is the gap this design answered on 2026-09-26 and has not built. + ## How a definition reads what was resolved **One form, naming a requirement and a field of its contract.** A definition that needs the database's diff --git a/04-ISSUES/119-a-module-definition-decides-where-its-files-live/00-report.md b/04-ISSUES/119-a-module-definition-decides-where-its-files-live/00-report.md index d7272c0..9d9dbf7 100644 --- a/04-ISSUES/119-a-module-definition-decides-where-its-files-live/00-report.md +++ b/04-ISSUES/119-a-module-definition-decides-where-its-files-live/00-report.md @@ -1,9 +1,9 @@ --- -status: located +status: resolved opened: 2026-09-25 located-in: [mesh-catalog modules, mesh-controller internal/catalogue] -fixed-by: -amended-design: +fixed-by: mesh-catalog PR 193 (the conversion), mesh-controller PR 170 (TestPlacedDirectoriesKeepTheirPaths, which proves it moved nothing); the placed-directory mechanism itself predates this in mesh-controller internal/catalogue/dir_into.go +amended-design: 03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md --- # 119 — A module definition decides where its files live on the machine @@ -133,3 +133,30 @@ not by any check. - What identifies an assignment, if a module may be assigned to one node more than once? - What would the contributions file carry instead of host paths, so a provider needs no identical-path mount? + +## Resolved, 2026-09-30 — the module's half; the mesh's half is issue 174 + +**A definition no longer decides where its own data lives.** Twenty-eight definitions that named their +data directories now place them: the module's root as `place: "."`, a sub-directory by its id, and every +host-side reference — bindings, secrets, own secrets, grants, receives, file paths, mounts, env-files — +as `${dir:}`. Twenty-eight others had already been written that way. Five directories whose id is +not their last segment keep their path as a placement, which is the exception the design allows and +the reason nothing else has to move for them. + +**Nothing moved, and a test says so.** The controller's `TestPlacedDirectoriesKeepTheirPaths` takes the +catalogue before and after, resolves every converted definition on the default root with the +controller's own rule, and compares it whole with the definition before it: identical for all +twenty-eight. So the retirement this record said was a data migration turned out not to be one, on +one condition — a node's default root is where the data already is, and every node's is — and the +machines see no change. A node that sets another root is the case this does not cover, and it does +not exist. + +**What remains is not this record's.** The 232 host paths still in the catalogue are where the mesh +writes what it makes for a module, under `/var/lib/mesh/`; design 27 says the mesh places +those itself, and it does not yet. That is [issue 174](../174-the-meshs-own-files-for-a-module-are-placed-by-the-definition/00-report.md). +The defects this record listed under *where that has already gone wrong* are unchanged by this and +stay in 174's scope where they concern the mesh's files; the operator's shared data stays an access +([ADR 0051](../../02-DECISIONS/0051-shared-data-is-the-operators.md)). + +The manifest change lands with the catalogue's next merge; the rollout is a rebuild that changes no +machine, checked by comparing each machine's plan before and after. diff --git a/04-ISSUES/174-the-meshs-own-files-for-a-module-are-placed-by-the-definition/00-report.md b/04-ISSUES/174-the-meshs-own-files-for-a-module-are-placed-by-the-definition/00-report.md new file mode 100644 index 0000000..e1ae843 --- /dev/null +++ b/04-ISSUES/174-the-meshs-own-files-for-a-module-are-placed-by-the-definition/00-report.md @@ -0,0 +1,48 @@ +--- +status: located +opened: 2026-09-30 +located-in: [mesh-controller internal/catalogue/dir_into.go, mesh-controller internal/catalogue/declaration.go, mesh-catalog modules] +fixed-by: +amended-design: +--- + +# 174 — The mesh's own files for a module are placed by the definition, not by the mesh + +## What was observed + +After every module's *own* data directory was placed by the mesh +([issue 119](../119-a-module-definition-decides-where-its-files-live/00-report.md)), the catalogue +still carries **232 host paths in 50 definitions**, all of one kind: where the mesh writes what it +makes *for* the module — its sealed bus credential (`own-secrets.broker`), its merged config file, its +bindings — under `/var/lib/mesh//…`, and the directory resource that creates that subtree. +Not one of those files is the module's. The mesh mints the credential, composes the binding, merges +the config; the definition only says where to put them, and says it the same way seventy times. + +## Why this is here + +Design 27's answer to *what sits beneath a node's root* (2026-09-26) is that the mesh's writes need no +module-visible reservation: **what the mesh writes for a module is the mesh's plumbing, placed where +the mesh chooses and mounted in, never part of the module's contract.** The definition today names +that place, so a definition is not yet free of host paths — and a node whose root is elsewhere would +place the module's data there and the mesh's files still under `/var/lib/mesh`. + +The path-preserving test that let issue 119 close does not cover this: it proves a *placed* directory +resolves to what was named, and these are not placed. + +## What it would take + +A word for "the mesh's file for this module", or none: `own-secrets` values, a merged config file and +a binding could be named by key alone, with the mesh choosing `/mesh//` and +mounting it where the container says. The container side of the mount already exists in every +definition (`/run/secrets/broker`, `/run/config/config.json`); only the host side would go. The +change is in the controller, once, and then a mechanical edit of fifty definitions, which the same +test that proved 119 can prove again with the rule extended. + +## Open questions + +- Does `own-secrets` keep its map shape with the value becoming the *container* path rather than the + host path, or does the mount stay where it is and the host side become a placeholder the mesh + fills, `${mesh:}`? +- A binding file today lands wherever `binds` says; a module's code reads it from an environment + variable naming the container path. If the host side is the mesh's, is the container side still the + definition's to choose? It should be: it is the software's contract. -- 2.54.0