Issue 169: the consumer's half — the host mounts the share, a mount is a resource of the consuming module, not a client module

2026-09-30 13:53:32 +02:00
parent e33191161d
commit 90b89aa1c9
1 changed files with 24 additions and 0 deletions
@@ -82,6 +82,30 @@ the catalogue beside the modules (a seat definition registered like a manifest),
 saying which seats it implements. This is the first role with an obvious second implementation,
 which is what makes it the exemplar for that mechanism.
 ## The consumer's half: the machine mounts it (2026-09-30, third round)
 A binding tells a consumer *where* the share is; it does not put the files on its machine. A
 consumer on another node needs the export **mounted by the host, at a directory the consumer
 declares, before its container starts**, and unmounted when the requirement goes. That is a host
 action, not something a container reads from a file.
 **Not a client module.** A node-wide `nfs-client` with a list of mounts in its settings is fstab
 with a manifest around it: consumers would stop requiring `nfs-share` and couple on a path again,
 unassigning a consumer would leave its mount behind, and a person is back in the loop deciding
 which machine mounts what — the thing the binding removes.
 **A mount is a resource of the consuming module.** The vocabulary (directory, file, package,
 container, service, process, network, archive, user, access) has no `mount`. It can be assembled
 today — a `package` (nfs-utils), a `file` writing a systemd `.mount` unit with
 `What=${bound:nfs-share:at}:${bound:nfs-share:path}` and `Where=${dir:library}`, a `service`
 enabling it after the overlay is up — but the honest form is a **`mount` resource kind**: the host
 mounts from the binding, refuses a mountpoint the module did not declare (ADR 0091's three ways a
 path can be), and unmounts on undeclare. The nfs and samba modules are then the *server* side only.
 **Identity crosses the wire.** `sec=sys` NFS trusts the client's uid, so a consumer must run as the
 library's owner on the server (ace: `media`, 1001:2000) — hq 153's `${access:<id>:uid}` proposal
 extended to a mount, `${mount:<id>:uid}`, read from the mounted tree.
 ## Open questions for the decision
 - Whether an NFS export over the overlay is an `internal` reach of the same endpoint or a second