2.0 KiB
REPORT — agent v0.22.0: expose durable_id in GET /disks (2026-06-11)
Repo: felhom-agent · Version: 0.22.0 · Pushed commit: 4734d4a · paired with
felhom-controller v0.43.0 (the controller-side storage-management rebuild that needs this).
What shipped (one read-only field)
internal/localapi/DiskInfo gains durable_id (mapped directly from StorageTarget.DurableID — e.g.
"uuid:<fs-uuid>" for usb/local-dir, "path:…"/"store:…" otherwise). That's the entire change.
Why it's necessary: the de-privileged controller cannot read a device's filesystem UUID itself, yet
POST /disks/assign mounts strictly by fs UUID (EnsureMount → /dev/disk/by-uuid/<UUID>). Without
the UUID surfaced somewhere the controller can reach, the guided init/attach flows could not complete the
mount. GET /disks already carried everything else (name/type/state/device/mount/class/data_bearing) but
dropped the durable id. The controller strips the uuid: prefix to get the assign key.
Security: no new privilege, no subprocess, no behaviour change to format/assign/eject or the
data-bearing signature gate. The agent still inspects the device itself at format time and refuses a
data-bearing wipe with a pending_op (the controller surfaces the felhom-opsign command).
Validation (live, guest 9201)
GET /disks (via the controller's /api/disks proxy) now returns durable_id per disk, e.g.
felhom-usb → /dev/sdb1, data_bearing:true, durable_id:uuid:277a2179-a764-4758-b840-9ea741517914.
The controller's guided init on sdb correctly drove the agent to a data-bearing refusal (HTTP 403 →
pending_op{op:storage_wipe, host_scope:demo-felhom-01, durable_id:byid:wwn-0x5000039ddb108568-part1}),
which the controller surfaced as the operator felhom-opsign command — the gate held end-to-end.
Notes
This pairs with the controller's storage-management rebuild (build-golden default bumped to controller 0.43.0; golden rebaked). No other agent change.