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

This commit is contained in:
2026-09-30 13:53:32 +02:00
parent e33191161d
commit 90b89aa1c9
@@ -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