jschoubben
220e3c72f5
Resolves 04-ISSUES/036: eight media modules each declared the shared library and download directories as their own resources, and the resolver's duplicate-owner refusal — right in general — would refuse the stack's only sensible assignment the first time two landed on one node. The decision, from the operator: shared, pre-existing data is operator-owned and external. The mesh does not create, chown, reconcile or remove it. A module declares it needs access to such a path (read or read-write); the host mounts it and owns nothing. Several modules accessing one path is normal — the duplicate-path refusal is about ownership, not use. An accessed path absent at apply is refused clearly, not created. Extends ADR 0030: the third case the host had no word for, what it neither made nor configured and must not touch. Point 036's fixed-by/amended-design at the record; mark it located in mesh-control, mesh-catalog and mesh-host. Regenerate the decision index. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
2.8 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |||
|---|---|---|---|---|---|---|---|
| located | 2026-09-02 |
|
02-DECISIONS/0051-shared-data-is-the-operators.md | 02-DECISIONS/0051-shared-data-is-the-operators.md |
036 — Six modules own what they must share
The symptom, as observed
Found by review of the catalogue examples (2026-09-02). The media stack is several modules — a library server, the acquisition managers, a download client and their satellites — and each of them declares the same library and download directories as its own resources.
The resolver refuses two modules that declare one path on one node, with no exemption for identical content and no merge. That rule is right in general: two owners of one path is the class of fault this repository keeps recording. But sharing those directories on one machine is the entire point of this stack — the download client and the managers must see the same downloads, the library server must see the same libraries. So the set, as written, refuses its own only sensible assignment.
No test co-resolves any two of them, which is why the manifests pass today. The first machine to be assigned the stack together is where the refusal would have surfaced.
Why it matters beyond the instance
The manifests can express a directory I own and nothing else, so a directory that is the shared workspace of several modules was written six times as six private ones. The intention — several modules, one filesystem contract between them — has no vocabulary, and this is not a media-stack peculiarity: any pipeline of modules handing files to each other on one machine (an ingest directory, a spool, a drop folder) hits the same wall.
It is also a fork in the design the catalogue has otherwise avoided: the fix could be a new owning module the others depend on, a shared-resource concept in the manifest, or a statement that co-located file handoff is not a thing the mesh supports and these modules are one module. Each answer changes what a module is, which is why this is an issue and not a patch.
Open questions
- Is the unit wrong — is a stack that must share a filesystem one module with several containers, the way the mail module already is?
- If it stays several modules: does one of them own the directories and the rest require them, and is requiring a directory from a neighbour a provision, a claim, or a third thing?
- The duplicate-path rule protects against genuinely rivalrous owners. Whatever expresses sharing must not weaken it for the cases where refusal is the right answer — what distinguishes the two, machine-checkably?
- The mesh's own rule is that a rule states how it is checked: whichever shape is chosen, what test co-resolves the stack so this class of refusal is caught before a machine is?