vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(#3044): stop mounting a child's harness dir into its parent

Browse source 
bind_child_agent_dirs looped over state, harness and config alike and
mounted all three read-write, while the doc comment above it defended
only state. The rationale covered one dir, the loop covered three — the
uniformity is what erased the fact that the three have three different
answers.

harness holds the child's own runtime material (bash-tasks, the
turn-stats and event sqlite dbs) and nothing argues for a parent
touching it. The only other reader is stats::hive_stats, which reads the
host path directly and needs no mount into anyone.

config stays read-write here on purpose. The ruling is that it becomes
read-only, but request_init_config still has the manager seed a new
child's config in place, so flipping the mount before relocating that
step breaks agent creation hive-wide. That ordering now lives in the doc
comment, where someone about to finish the job in one line will see it.

docs/persistence.md justified all three dirs as RW; it now states the
boundary as three answers and names the right source file.
This commit is contained in:
atlas 2026-08-10 20:28:09 +02:00
commit 609035961f
2 changed files with 94 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

36
docs/persistence.md
View file

@ -314,19 +314,29 @@ Under `/var/lib/hyperhive/agents/<name>/`:
### Parent access to child state
A parent agent gets each direct child's `state`, `harness`, and
`config` dirs bind-mounted **read-write** (`bind_child_agent_dirs` in
`lifecycle.rs`). The RW on `state` is deliberate, not an oversight: a
parent manages its children, which includes writing into a child's
state for recovery (e.g. seeding notes, clearing a stuck sentinel) as
well as reading it. `config` and `harness` are RW too, but **nothing
justifies that for `config`**: a config change is a PR on the child's
config repo, made from a clone, so the bind-mounted `config` dir is a
read-only *copy* for reading a child's config — not a tree anyone edits
in place. Narrowing it is tracked separately, and depends on relocating
where `InitConfig` seeds. Per-child isolation still holds: a container only ever has
its *own* dirs plus its direct children's bind-mounted, never a
sibling's.
A parent agent gets each direct child's `state` and `config` dirs
bind-mounted **read-write** (`bind_child_agent_dirs` in
`lifecycle/host_config.rs`). The RW on `state` is deliberate, not an
oversight: a parent manages its children, which includes writing into a
child's state for recovery (e.g. seeding notes, clearing a stuck
sentinel) as well as reading it.
**`harness` is not mounted at all.** It holds the child's own runtime
material — `bash-tasks/`, the turn-stats and event sqlite dbs — and
nothing argues for a parent reading it, let alone writing it. It used to
be mounted RW for "the same management reasons" as `state`, which was
never an argument so much as the side-effect of one loop treating all
three dirs alike. hive-c0re reads a child's harness dir **directly on the
host** when it wants those stats, which needs no mount into the parent.
`config` is still RW, and **nothing justifies that**: a config change is
a PR on the child's config repo, made from a clone, so the bind-mounted
`config` dir is a read-only *copy* for reading a child's config — not a
tree anyone edits in place. Narrowing it is tracked separately, and
depends on relocating where `InitConfig` seeds.
Per-child isolation still holds: a container only ever has its *own*
dirs plus its direct children's bind-mounted, never a sibling's.
Under `/var/lib/hyperhive/applied/<name>/` — the hive-c0re-only
applied repo. Tracks `flake.nix` (module-only boilerplate; never