49 lines
3.3 KiB
Markdown
49 lines
3.3 KiB
Markdown
# REPORT — felhom-controller: slice 10 (external user-data drives) — controller side
|
||
|
||
**Version:** 0.50.0 · **Date:** 2026-06-12 · pairs with **felhom-agent v0.25.0–v0.27.0**
|
||
|
||
The controller's half of slice 10 (the agent owns the host-side execution + self-heal; see
|
||
felhom-agent's REPORT for P1 spike / P2 passthrough / P2 activation endpoint / P3 self-heal). All
|
||
live-validated on guest 9201; golden rebaked to 0.50.0.
|
||
|
||
## P2C — enroll passes the drive into the guest (v0.48.0)
|
||
- `agentapi.GuestAttach(where)` → agent `POST /disks/guest-attach`. `runStorageInit` /
|
||
`runStorageAttach` / `handleStorageRegister` call `attachIntoGuest` after recording the StoragePath
|
||
(best-effort; a transient failure is logged — P3 self-heal completes it). Closes Branch A: an enrolled
|
||
drive becomes usable in the guest (app `HDD_PATH` writes land on `/dev/sdb1`; the "nem elérhető"
|
||
banner clears).
|
||
|
||
## Activation-UX (v0.49.0)
|
||
- The host-side live inject is blocked on unprivileged LXC, so a drive enrolled into a *running* guest
|
||
activates at the next guest boot. Per decision: enroll persists (no forced reboot) + a user-triggered
|
||
restart.
|
||
- `pendingActivationDrives()` flags registered drives the agent reports present+attached but which
|
||
aren't a live mount in the container. The settings page shows a banner + a batched **"Újraindítás
|
||
most (~30 mp)"** button → `POST /api/storage/activate` → `agentapi.GuestReboot` → agent
|
||
`POST /guest/reboot`. Live-validated: activate → guest reboots → drive active.
|
||
|
||
## P4 — dual-role drives + backup-aware wipe warning (v0.50.0)
|
||
- **4A:** a user-data drive is appdata AND backup-target-eligible (not locked to one role) — surfaced
|
||
in the drive overview's per-card purpose note. `felhom-pbs`/system/backup roles unchanged.
|
||
- **4B:** `handleStorageImpact` now also returns `backup_copies` — apps whose cross-drive (secondary)
|
||
backups are stored on the drive (`backupCopiesOnPath` scans `felhom-data/backups/secondary/<app>`,
|
||
skipping the shared restic repo / `_infra`). The type-to-confirm wipe/eject modal names them ("Ez a
|
||
meghajtó más alkalmazások biztonsági másolatait is tárolja — a törlés ezeket is eltávolítja"). The
|
||
wipe stays **customer-confirmable** (the copies are redundant; originals live on the source drive).
|
||
- **OUT OF SCOPE:** the cross-drive backup ENGINE (restic USB1↔USB2, scheduling, pruning) — a follow-on
|
||
slice (needs a 2nd physical drive to validate). The 4B detection is forward-compatible (empty until
|
||
the engine writes there).
|
||
|
||
## Live validation (9201)
|
||
- P2C: app bytes on `/dev/sdb1`, banner `[PASS] 1 connected, 0 disconnected`.
|
||
- Activation: `/api/storage/activate` → reboot → drive active.
|
||
- P4: `/api/storage/impact?where=/mnt/felhom-usb` → `backup_copies:[]`; after creating
|
||
`felhom-data/backups/secondary/immich` → `backup_copies:["immich"]` (detection live).
|
||
- `go test ./internal/{web,agentapi}/` green; golden rebaked to 0.50.0, build guest purged.
|
||
|
||
## Note (carried from P2)
|
||
The controller's app/backup path helpers still join `felhom-data` under the registered drive path; in
|
||
Model A the in-guest mount IS the felhom-data namespace, so backup paths double-nest
|
||
(`felhom-data/felhom-data/...`) — functional but untidy. Reconcile when wiring app-data-backup-to-drive
|
||
(not in this slice; app `HDD_PATH` data lands correctly today).
|