| Filename | Latest commit message | Latest commit date |
|---|---|---|
a6dc980700
The hive applies one `agentCpuQuota` / `agentMemoryMax` to every
container. That's the right default and the wrong ceiling: a build-heavy
agent needs headroom the other twelve don't, and raising the hive-wide
value to suit it hands that headroom to everyone.
Adds a per-agent override, persisted host-side and resolved per-field
against the hive defaults.
Follows the existing `meta/*.json` pattern (`capabilities.json`,
`tool-groups.json`): a host-side map read by `hive-c0re`, staged and
committed in the meta repo so every change lands in the audit trail.
```json
{ "sock": { "cpu_quota": "400%", "memory_max": "8G" } }
```
Fallback is **per field**, not per agent: an entry with only
`memory_max` leaves that agent on the hive-wide CPU quota. Absent file,
absent agent and absent field all resolve to the hive default, so the
feature is inert until someone opts an agent in.
Unlike the other meta files this one is **not** injected into the
container — a limit is something done *to* an agent, not something it
reads about itself.
```
hivectl agents set-limits sock --cpu-quota 400% --memory-max 8G
hivectl agents set-limits sock --reset
```
Values are validated before they're persisted: they go into a systemd
drop-in verbatim, and a typo there makes the unit fail to *start* —
turning a fat-fingered quota into a container that won't come back.
The command is declarative: each call replaces the agent's whole entry.
That makes a forgotten flag a silent revert, so a bare `set-limits
<name>` is rejected at the clap layer and clearing needs an explicit
`--reset`.
`ContainerView` gains `cpu_quota` / `memory_max`, both always populated:
there's no "unset" state to render, only "same as everyone else". They
reflect what the drop-in *says* — what the next start will enforce — not
a live cgroup reading.
The write goes through `meta::commit_resource_limits` rather than the
bare setter, so it's staged and committed under `META_LOCK`. Writing
without committing would leave the meta working tree dirty for the next
`prepare_deploy` to trip over.
Docs: `persistence.md` (the new meta file, and why it isn't injected),
`tools/hivectl.md` (the prose guide), `tools/hivectl-cli.md`
(regenerated clap dump).
Closes: internal/requests issue 25
|
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
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.