Files
felhom-controller/REPORT.md
T

73 lines
4.7 KiB
Markdown

# REPORT — felhom-controller v0.45.0: storage UX polish (order, init filter, register shortcut, clarity)
**Repo:** `felhom-controller` · **Version:** 0.45.0 · **Date:** 2026-06-12 · pairs with **felhom-agent v0.24.0**
Part B of the storage-fixes spec — controller-side ordering/filter/clarity polish on top of v0.44.0's
role-aware drive management. (Part A, the eject role-gate, lives at the agent — see felhom-agent
v0.24.0 / its REPORT.)
## What changed
### B1 — deterministic disk order (`internal/web/agent_disk_handlers.go`)
`agentDisksListHandler` sorts the agent's drive list server-side before rendering (`sortDisksForView`):
**user-data → system → backup** (then unrecognized), alphabetical by storage name within each tier.
The agent's storage view iterates an unordered Go map, so the list previously reordered on every reload
(CLAUDE.md lesson #3). A stable Go-side contract beats relying on map order or template JS.
Test: `TestSortDisksForView`.
### B2 — init wizard excludes mounted drives (`templates/storage_init.html`)
The `formattable` filter gained `&& !d.mount_path` (matching the attach wizard): an already-mounted
drive (e.g. `felhom-usb`) no longer appears as an "initialize" candidate. Eject it first to make it an
init target.
### B3 — register shortcut for a mounted-but-unregistered user-data drive
- New `POST /api/storage/register``handleStorageRegister` → reuses `registerStoragePath` (the
manual-add path): records the existing mount into the `StoragePath` registry (no format, no eject),
then FileBrowser-syncs. `AddStoragePath` dedupes (clean error on double-register).
- `settings.html`: a mounted, **unregistered** user-data drive now shows **Regisztrálás** as its
PRIMARY per-card action; Leválasztás/Törlés stay secondary.
### B4 — system-storage clarity (presentation only, `settings.html` + `style.css`)
`local` and `local-lvm` are both kept (not collapsed). Each card now carries:
- a plain-Hungarian **purpose description** keyed on the agent's `type`/`role` (`purposeDesc`):
local-lvm → internal SSD (system, Docker, app **databases**); local → host storage, **no app data**;
pbs → backups; user-data → external store for large app files.
- an **app-backing tag** (`appBackingTag`): `local-lvm` → "Alkalmazás-rendszer"; user-data →
"Alkalmazás-adatok".
- a one-line **tiering note** above the list answering "which storage do the apps use?".
Role/type stay authoritative from the agent — no agent contract change.
### B5 — eject confirmation names affected apps
Already wired pre-existing: `confirmEject` → the type-to-confirm modal fetches `/api/storage/impact`
and lists, by name, the deployed apps that lose their storage (parity with the wipe warning). Verified,
no code change needed.
## Build / deploy
- Built `felhom-controller:0.45.0` on the build server (`build.sh 0.45.0 --push`).
- Deployed to **guest 9201** on `felhom-pve`: `docker pull`, updated `/etc/felhom-controller-image`,
re-ran `felhom-controller-bootstrap.sh` → container recreated on `0.45.0`, **healthy**;
`[selfupdate] Current version 0.45.0 is up to date`.
- CHANGELOG (newest on top) + `controller/README.md` (Storage Management section) updated.
## Live validation (guest 9201, auth disabled on this demo → API reachable)
- **B1 order:** `GET /api/disks` returns `[felhom-usb(user-data), local(system), local-lvm(system),
felhom-pbs(backup)]` — **stable across 3 reloads** (user-data first, system alpha, backup last).
- **B2 filter:** the only user-data drive (`felhom-usb`) has a `mount_path`, so the new filter excludes
it from init candidates (confirmed by the live disk data).
- **B3 register:** `POST /api/storage/register {where:/mnt/felhom-usb}` → `{registered:true}`;
`settings.json` now lists `/mnt/felhom-usb` (label "Tárhely (felhom-usb)", schedulable);
`FileBrowser mounts synced — 1 storage path(s)`.
- **B5 impact:** `GET /api/storage/impact?where=/mnt/felhom-usb` → `{apps:[], where:…}` (valid wiring;
no deployed app currently routes data there).
- **B4 clarity:** pure presentation rendered client-side from the agent's role/type (templates
parse-tested; the disk data carries the keys the JS branches on). Visual confirmation is a browser
check.
- `go test ./...` green for the whole module.
## Not done / human step
- **Golden rebake** (to bake controller 0.45.0 into new-guest templates): NOT performed — `felhom-pve`
has no registry credentials (`REGISTRY_USER`/`REGISTRY_TOKEN`, stored out-of-band) and there is no
golden archive currently on the host. Controller **self-update covers the drift** (a freshly
provisioned guest would self-update to 0.45.0), so existing + new guests converge regardless. The
rebake remains a human/credentialed operational step.