hyperhive/hive-host-sock
Repository files (latest commit first)
Filename Latest commit message Latest commit date
atlas 282bbc3709 feat(#2862): push a snapshot to a peer hive's store over the mesh
Adds the caller the fd-passing machinery existed for: hivectl agent
<name> subvol snapshot push --peer <hive> resolves the peer, connects
to its snapshot store, writes the agent header, and hands the connected
socket to hive-priv, which runs btrfs send straight into it.

The split keeps the root helper ignorant. Everything that involves
knowing where a peer is, what the wire protocol looks like, and which
hive to trust happens in the unprivileged daemon; hive-priv only ever
receives an already-open descriptor. Once btrfs send starts, neither
process is in the data path, so a multi-gigabyte transfer costs no
per-byte work and survives a hive-c0re restart.

call_with_fd takes the descriptor by value and closes it as soon as the
kernel has it. A socket stays open until every copy closes, so holding
one back would leave the receiver waiting for an EOF that never comes:
btrfs receive blocks and this side reports success for a transfer the
peer never committed. Ownership makes that unrepresentable.

The peer's store port is a new swarm.peers.<domain>.snapshotStorePort
option rather than a constant matching the module default. A pushing
hive cannot read the receiver's configuration, so assuming 51821 would
push at a port nobody promised to listen on; absent, the push fails
naming the option. swarm_peers parses the mesh address the host module
has always rendered into HYPERHIVE_PEERS but nothing read.
2026-07-31 22:15:37 +02:00
..
src feat(#2862): push a snapshot to a peer hive's store over the mesh 2026-07-31 22:15:37 +02:00
Cargo.toml refactor(#2808): the wire state enum is the scheduler's own 2026-07-27 21:50:24 +02:00
README.md docs(#2627): add READMEs for hive-jobq + the socket wire crates 2026-07-23 12:34:22 +02:00

hive-host-sock

Wire types for the host admin socket (/run/hyperhive/host.sock) — the host-control protocol spoken between the hivectl operator CLI and the hive-c0re daemon.

Why it's its own crate

Re-homed out of hive-sh4re so a standalone hivectl depends on just this protocol crate instead of the whole daemon-shared crate. hivectl drives the full hive (spawn / kill / destroy / rebuild / deploy) over this socket without linking hive-c0re; keeping the request/response shapes here is what makes that thin dependency possible.

Shape

Serde-derived request/response enums for the host admin protocol. The larger shared payload types some variants reference (Approval, AgentStatusRow, jobs::DagView) stay in hive-sh4re — this crate is only the protocol envelope, no server or client implementation.

See docs/boundary.md (host admin socket access) for the trust model around who may connect to the socket, and hive-priv-sock for the sibling split on the privileged-helper socket.