Files
felhom-controller/REPORT.md
T
2026-07-01 21:26:34 +02:00

4.2 KiB

REPORT — Impl-2b: enrollment wizards → /disks/candidates + end-to-end raw enrollment (controller v0.95.0)

Date: 2026-07-01 · Repo: felhom-controller · Class: Risky/supervised (first live raw enrollment runs the Impl-1 guarded mkfs inside a real enroll). Companion agent work: v0.55.0→v0.58.0.

Final piece of the drive-enrollment series: both enrollment wizards now source candidates from the agent's raw-device scan, so a brand-new (non-PVE-storage) drive is discoverable + enrollable end-to-end.

1. Baseline → target

felhom-controller 6ce61e8 (v0.94.0) → v0.95.0. Agent v0.55.0 → v0.58.0 (separate repo — the raw-drive path needed agent fixes the spec's "N/A agent" premise didn't anticipate; see agent REPORT).

2. Files changed + commits

  • internal/agentapi/client.goListCandidates + CandidatesResult/DiskCandidate (mirror the agent's /disks/candidates).
  • internal/web/agent_disk_handlers.goGET /api/disks/candidates passthrough proxy.
  • templates/storage_init.html / storage_attach.html — fetch /api/disks/candidates; render initialize / attach; dropped the client-side "already-managed" filter.
  • internal/web/storage_handlers.goresolveEnrollUUID: a raw candidate isn't in /disks, so resolve its fs-UUID from /disks/candidates (the enroll blocker the "reuse unchanged" premise missed). Both runStorageInit + runStorageAttach use it.
  • Tests: agentapi TestListCandidates(+_Error), web TestRunStorageAttach_RawCandidate(+red-proof).
  • CHANGELOG.md, README.md. Commits feab92c (wiring) + bea05ea (resolveEnrollUUID) on main.

3. Green gate

go build ./..., go vet ./..., go test ./... — clean. Image felhom-controller:0.95.0 built on 180, deployed to guest 9201 (golden/bootstrap), Up (healthy).

4. End-to-end live validation (real UI, claude-in-chrome, felhom.demo-felhom.eu)

Step Result
Discovery (init wizard) /dev/sdd (SD/MMC/MS PRO, 59 GB, ext4) offered as the sole candidate; sda/sdb/sdc NOT shown.
Format via Impl-1 guard enroll ran the guarded mkfs on /dev/sdd (formatted device … fstype=ext4) — the first real customer-flow guarded format.
Discovery (attach wizard) the ext4 /dev/sdd offered under attach.
Enroll end-to-end wizard attach → resolveEnrollUUID → mount (/mnt/teszt_enroll) → bind (/mnt/felhom-drives/teszt_enroll) → intent enrolled → guest-bind recorded → registered. UI shows "Aktív" (USB), alongside felhom-usb + felhom-flash, all Active — no false detach.
Health-tracked the watchdog (RegistryKnownTargets) detected + self-healed a drop of the drive during testing.

Note on the init slow-format path: a slow device (the 60 GB SD card, ~25 s mkfs) exceeds the controller→agent request timeout; runStorageInit calls FormatDisk synchronously and does NOT poll the agent's detached-format status (/disks/format/status), so on a slow device it aborts after the format detaches and the mount/bind back-half doesn't run. Pre-existing (F20-BUG3-adjacent; not the Impl-2b wiring). The end-to-end above was completed via the attach path (no mkfs) — which fully exercises the candidate→enroll→active pipeline. Follow-up: make runStorageInit poll the detached-format status.

5. NOT done / follow-ups

  • Init slow-format polling (above) — runStorageInit should poll /disks/format/status so a slow-device format completes the enroll in one flow.
  • Impl-3 — the shared-box operator gate for self-serve format (raw-passthrough blind spot). The demo is a dedicated box, so self-serve format is appropriate there.
  • The throwaway /dev/sdd (SD card) is left enrolled + Aktív as living proof; the operator can eject it via the UI (Leválasztás) and unplug when done.

6. Observations

  • The spec's premise ("just wire the wizards; the enroll flow already works") was optimistic: the entire enroll + tracking machinery assumed a PVE-storage drive (Observe()), so making raw drives first-class required resolveEnrollUUID here + a chain of agent fixes (see agent REPORT). All shipped + validated.