admin
cae2bfbe5b
REPORT (Phase 4 FileBrowser scoping + deploy note + monitoring descriptions; live validation; full slice summary 1/2/2b/3/4 all shipped + validated v0.52->v0.56). CONTEXT entry. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
47 lines
3.4 KiB
Markdown
47 lines
3.4 KiB
Markdown
# REPORT — felhom-controller v0.56.0 (Phase 4: FileBrowser scoping + UI polish) — SLICE COMPLETE
|
|
|
|
Phase 4 closes the per-app-recovery-unit / Tier-2 slice. Built, deployed, and live-validated on guest
|
|
9201. With this, **all five phases of the spec (1, 2, 2b, 3, 4) are shipped and live-validated** — see
|
|
git history (v0.52 → v0.56).
|
|
|
|
## Phase 4 — what shipped (v0.56.0)
|
|
- **4A FileBrowser scoping (safety):** the FileBrowser bind mount is scoped to each drive's `appdata/`
|
|
subtree (`<drive>/appdata:/srv/<name>`) instead of the whole drive root. The recovery units + Tier 2
|
|
copies under `backups/` are **not mounted into FileBrowser at all** — the customer browses their
|
|
userdata but cannot reach (or see) the thing that restores them. `syncFileBrowserMounts` mkdir's the
|
|
appdata dir before binding; it runs on controller startup, so the scoping applies immediately.
|
|
- **4B Deploy-UI communication:** the storage-selection step states plainly (Hungarian) that the chosen
|
|
drive holds the app's **files**, while its **database runs on the fast internal SSD** and is backed up
|
|
alongside the app — so the DB-on-SSD split stops being a surprise.
|
|
- **4C Monitoring storage list:** `buildStorageBars` sorts deterministically (by path) and carries a
|
|
**purpose description** for the user-data drives, rendered on the monitoring "Tárolók kapacitása" list.
|
|
(Correction to the spec's premise: this list is the controller's registered **user-data** drives only —
|
|
the agent's local/local-lvm/pbs storage is not in this registry, so the role-tier sort and
|
|
`local`-vs-`local-lvm` descriptions live on the agent-backed storage-management page, not here.)
|
|
|
|
## Live validation (guest 9201)
|
|
- **4A:** after deploy, FileBrowser's mount is `/mnt/felhom-usb/appdata -> /srv/felhom-usb`; `/srv/
|
|
felhom-usb` lists `romm` (userdata) and the recovery units at `/mnt/felhom-usb/backups` are outside the
|
|
mount — confirmed via `docker inspect`.
|
|
- **4B:** the deploy page (nextcloud) renders "…adatbázis a gyors belső SSD-n…".
|
|
- **4C:** the monitoring page renders "Külső adattároló — … az adatbázisok a belső SSD-n vannak."
|
|
|
|
## Slice summary (all live-validated on guest 9201)
|
|
- **Phase 1 (v0.52.0):** deploy-side Model-A double-nest fix (catalog templates) + deploy↔backup path
|
|
agreement test; RomM migrated.
|
|
- **Phase 2 (v0.53.x):** per-app **secret-free** recovery unit (compose + secret-stripped app.yaml +
|
|
db-dumps + volume-dumps + manifest), idempotent capture.
|
|
- **Phase 2b (v0.54.0):** restore-from-unit recreate + **fail-closed `data_key` gate** (proven live on
|
|
AdventureLog: refused when the encryption key was unrecoverable).
|
|
- **Phase 3 (v0.55.0):** auto **off-drive Tier 2** with the **rootfs-headroom guard** (refuse-not-fill,
|
|
proven live).
|
|
- **Phase 4 (v0.56.0):** FileBrowser scoping + deploy DB-on-SSD note + monitoring descriptions.
|
|
|
|
## Known follow-ups (small, optional)
|
|
- Off-disk identity uses block-device equality; the agent's `DiskInfo.DurableID` is stronger for the
|
|
same-disk-multiple-partitions case.
|
|
- Non-HDD apps' "2. mentés" card shows "Nincs 2." (they're in PBS); could be hidden for them.
|
|
- The README backup-paths section still has stale restic/secondary text (flagged inline) — worth a pass.
|
|
- Full readable-data restore e2e vs AdventureLog couldn't run on the 8 GB demo rootfs (images too big);
|
|
the gate + recreate are unit/integration-tested and the fail-closed path is proven live.
|