From 76a570da3284a742829cfeabe588255e3c74095f Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Fri, 12 Jun 2026 21:08:27 +0200 Subject: [PATCH] docs: REPORT.md for v0.51.0 (offsite-backup UI + double-nest fix) Co-Authored-By: Claude Opus 4.8 (1M context) --- REPORT.md | 81 ++++++++++++++++++++++++++----------------------------- 1 file changed, 38 insertions(+), 43 deletions(-) diff --git a/REPORT.md b/REPORT.md index f70082b..741748d 100644 --- a/REPORT.md +++ b/REPORT.md @@ -1,48 +1,43 @@ -# REPORT — felhom-controller: slice 10 (external user-data drives) — controller side +# REPORT — felhom-controller v0.51.0 -**Version:** 0.50.0 · **Date:** 2026-06-12 · pairs with **felhom-agent v0.25.0–v0.27.0** +Offsite-backup UI (felhom-pbs = real DR) + Model-A double-nest fix. Pairs with felhom-agent v0.28.0 +(whole-guest backup re-targeted to the offsite PBS tier). Live-deployed in guest 9201 on demo-felhom. -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. +## Backups page — whole-guest backup shown as real DR +- `backupTargetLabel` returns **"Biztonsági szerver – külön hardver (PBS)"** for a PBS-stored backup + (detected via `backupIsPBS` on the target id / archive volid), so the customer sees the backup + survives a host hardware failure. +- The app-data section's **"Távoli mentés"** card stops reading "nincs beállítva": new + `guestBackupView.Offsite` flag drives it to **"külön hardveren (PBS)"** with a ✓ when the whole-guest + backup landed on PBS. +- The restore-test "Visszaállítás ellenőrizve" trust signal is unchanged (already wired). +- Live: agent `/backup/status` reports `target_id=felhom-pbs`; `/restore-test/status` reports + `pass:true, verified:"boot+running", source_tier:"pbs"` → the page renders the PBS label, the offsite + card, and verified-restorable. -## 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). +## Model-A double-nest fix +- Under slice-10 Model A the host agent binds `/felhom-data` onto the guest mountpoint, so an + enrolled drive's in-guest mount IS the felhom-data namespace root (basename need not be `felhom-data`, + e.g. `/mnt/felhom-usb`). The backup path helpers were re-prepending `felhom-data`, producing + `.../felhom-data/felhom-data/...` on the host (confirmed live: `/mnt/felhom-usb/felhom-data/felhom-data/...`). +- `appbackup` path helpers now take a **namespace ROOT** (no internal `felhom-data` join) plus a new + `NamespaceRoot(drivePath, inGuestDrive)`. `backup.Manager.namespaceRoot`/`AppNamespaceRoot` resolve + provenance (`drivePath != systemDataPath` ⟺ a registered in-guest drive → namespace root as-is; the + SSD-only `systemDataPath` fallback appends `felhom-data`). +- All parallel constructions updated coherently so writes, deletion (`GetStackBackupData`, + `RemoveStack` backups-base + `ProtectedHDDPaths` — legacy double-nest dirs KEPT protected), the + wipe-warning secondary scan, and export all agree. `api.router` passes the namespace root across the + package boundary. Result: a drive-resident app's DB-dump lands single-nested at `/backups/...` + in-guest = `/felhom-data/backups/...` on the host. +- New `appbackup` test asserts no doubled `felhom-data` segment for an in-guest drive and exactly one + for the system fallback. Full `go build ./...` + tests green. -## 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. +## Decommission (P3) — NO controller change +- Permanent decommission is operator-signature-gated (never customer-confirmable), so it is wired + entirely agent-side (hub jobs-queue → signed-jobs runner). The controller deliberately exposes no + decommission UI. (felhom-agent v0.28.0.) -## 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/`, - 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). +## Live deploy +- `gitea.dooplex.hu/admin/felhom-controller:0.51.0` running + healthy in guest 9201 (bootstrap-launched + via `/etc/felhom-controller-image`; prior 0.50.0). Startup clean (catalog sync, health ok, + FileBrowser mounts synced).