novox/hq
3
0
Fork 0
Code Issues 4 Pull Requests Releases Wiki Activity

Issue 169: a machine shares its files, and the mesh does not know #215

Merged
mesh-admin merged 6 commits from issue/169-a-machine-shares-files-and-the-mesh-does-not-know into main 2026-10-01 09:24:12 +00:00
Conversation 4 Commits 6 Files Changed 1
+128
mesh-admin commented 2026-09-30 11:49:27 +00:00
Contributor
Copy Link
Copy Source

ace exports the operator's media library over NFS and Samba with host
services no module declares: they close at converge, nothing owns their
configuration, and no module elsewhere can require the share. Proposes a
file-sharing module that accesses the paths, holds a node-scoped seat it
defines, and provides file-share to consumers.

ace exports the operator's media library over NFS and Samba with host services no module declares: they close at converge, nothing owns their configuration, and no module elsewhere can require the share. Proposes a file-sharing module that accesses the paths, holds a node-scoped seat it defines, and provides file-share to consumers.
mesh-admin added 1 commit 2026-09-30 11:49:27 +00:00
Issue 169: a machine shares its files, and the mesh does not know 8d9c9ab6b5 
ace exports the operator's media library over NFS and Samba with host
services no module declares: they close at converge, nothing owns their
configuration, and no module elsewhere can require the share. Proposes a
file-sharing module that accesses the paths, holds a node-scoped seat it
defines, and provides file-share to consumers.
mesh-admin commented 2026-09-30 11:50:33 +00:00
Author
Contributor
Copy Link
Copy Source

Amended per the operator: file sharing is a core seat family, node-scoped and defined by the control plane — one seat per protocol (node-nfs-share → nfs-share, node-smb-share → smb-share, …) as ADR 0109 does for package registries, so nfs and samba modules each hold theirs on the same machine and one module may hold several.

Amended per the operator: file sharing is a **core seat family**, node-scoped and defined by the control plane — one seat per protocol (`node-nfs-share` → `nfs-share`, `node-smb-share` → `smb-share`, …) as ADR 0109 does for package registries, so nfs and samba modules each hold theirs on the same machine and one module may hold several.
jschoubben added 1 commit 2026-09-30 11:50:34 +00:00
Issue 169: file sharing is a core seat, one per protocol a0a930b1cd 
The operator's call: a node-scoped system seat family (node-nfs-share,
node-smb-share, …) defined by the control plane, one per protocol as
package registries are (ADR 0109), so several modules occupy it and a
machine may hold both.
jschoubben added 1 commit 2026-09-30 11:52:21 +00:00
Issue 169: two module-defined seats, and the gap — a seat definition has no neutral home e33191161d 
nfs-share and smb-share share an intent, not a contract; one seat would be
a union with every field optional. What the exemplar exposes is that a
seat declared inside one module cannot be implemented by another without
depending on it.
mesh-admin commented 2026-09-30 11:52:22 +00:00
Author
Contributor
Copy Link
Copy Source

Settled after two rounds with the operator: two module-defined seats, nfs-share and smb-share (they share an intent, not a contract — the table in the report), nfs/samba as first implementations. The design gap the exemplar exposes: a seat definition has no home outside the module that first declares it, so a second implementation (Ganesha, ksmbd) cannot hold the seat without depending on the first — the report proposes a neutral seat definition in the catalogue, registered like a manifest.

Settled after two rounds with the operator: **two module-defined seats**, `nfs-share` and `smb-share` (they share an intent, not a contract — the table in the report), `nfs`/`samba` as first implementations. The design gap the exemplar exposes: a seat definition has no home outside the module that first declares it, so a second implementation (Ganesha, ksmbd) cannot hold the seat without depending on the first — the report proposes a neutral seat definition in the catalogue, registered like a manifest.
mesh-admin commented 2026-09-30 11:53:33 +00:00
Author
Contributor
Copy Link
Copy Source

Third round: the consumer half. A consumer on another node needs the export mounted by its host before its container starts — not an nfs-client module (fstab with a manifest around it), but a mount resource of the consuming module, filled from the binding (What=${bound:nfs-share:at}:${bound:nfs-share:path}, Where=${dir:library}), unmounted on undeclare. Expressible today as package + systemd .mount file + service; the honest form is a new mount resource kind. nfs/samba modules are server-side only. Identity crosses the wire with sec=sys: ${mount:<id>:uid} (153 extended).

Third round: the consumer half. A consumer on another node needs the export mounted by its **host** before its container starts — not an `nfs-client` module (fstab with a manifest around it), but a `mount` **resource of the consuming module**, filled from the binding (`What=${bound:nfs-share:at}:${bound:nfs-share:path}`, `Where=${dir:library}`), unmounted on undeclare. Expressible today as package + systemd .mount file + service; the honest form is a new `mount` resource kind. nfs/samba modules are server-side only. Identity crosses the wire with sec=sys: `${mount:<id>:uid}` (153 extended).
jschoubben added 1 commit 2026-09-30 11:53:35 +00:00
Issue 169: the consumer's half — the host mounts the share, a mount is a resource of the consuming module, not a client module 90b89aa1c9
mesh-admin commented 2026-09-30 11:56:09 +00:00
Author
Contributor
Copy Link
Copy Source

Fourth round, correcting the third: no mount resource kind — mounting is a module's work. A consumer-side network-share module (package + systemd .mount unit as a file + service, filled from ${bound:nfs-share:…}, mountpoint as the assignment's setting); app modules reach the files through an access on that path, so the same app manifest runs against a local library on ace and a mounted one elsewhere. The one check to add is the data-loss case: an access on a mountpoint must be confirmed mounted, or a writer starting first writes into the empty directory underneath.

Fourth round, correcting the third: **no `mount` resource kind** — mounting is a module's work. A consumer-side `network-share` module (package + systemd .mount unit as a file + service, filled from `${bound:nfs-share:…}`, mountpoint as the assignment's setting); app modules reach the files through an `access` on that path, so the same app manifest runs against a local library on ace and a mounted one elsewhere. The one check to add is the data-loss case: an `access` on a mountpoint must be confirmed *mounted*, or a writer starting first writes into the empty directory underneath.
jschoubben added 1 commit 2026-09-30 11:56:10 +00:00
Issue 169: the consumer half is a module (network-share), not a host resource kind; the access-on-a-mountpoint check is the data-loss case ee801a6441
jschoubben added 1 commit 2026-09-30 11:56:27 +00:00
Issue 169: network-share is the module responsible for a node's network shares — a node role 105ae9a56a
mesh-admin merged commit bfc410fafe into main 2026-10-01 09:24:12 +00:00
mesh-admin deleted branch issue/169-a-machine-shares-files-and-the-mesh-does-not-know 2026-10-01 09:24:12 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
jschoubben miel.truyen
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/hq#215