Files
felhom-controller/REPORT.md
T
admin 036a6078bb docs: REPORT.md — v0.81.0 deployed to guest 9201 + live-verified
Banner gone, "Kiszolgáló újraindítása" card present + ordered after the
controller-restart card, /api/server/reboot -> 202, /api/storage/activate -> 404,
/api/selfrestart regression OK. Live end-to-end reboot of guest 9201 confirmed
via agent logs (guest back up, drives re-bound, controller recovered healthy).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PsnU2ASocYrvzqE82YDYW
2026-06-23 18:54:09 +02:00

5.0 KiB

REPORT — retire drive-activation banner; add standalone "Kiszolgáló újraindítása" button

Repo: felhom-controller · Baseline: main @ 7cce19797 (v0.80.0) → v0.81.0 Commit: 242b835 (code + CHANGELOG + README). Date: 2026-06-23.

Why

In the intermediary-mount model an enrolled drive binds live into the running guest (agent disks.go — no pct set -mpN, no slot, no reboot), so the "… meghajtó aktiválásra vár / Újraindítás most (~30 mp)" banner was an obsolete relic of the old per-drive reboot model. It was also effectively dead since v0.78: pendingActivationDrives keyed attached by the agent's RAW MountPath but compared it to the now-STABLE sp.Path. Retired it; added a deliberate full-server restart affordance in its place (sibling to the controller-only restart).

Files changed

  • controller/internal/web/storage_handlers.go
    • Removed dead pendingActivationDrives helper + the now-unused internal/system import.
    • Renamed handleStorageActivateHandleServerReboot; split out testable serverReboot(w,r,agent) core.
    • Added GuestReboot(ctx) error to the diskAgent interface (*agentapi.Client already satisfies it).
    • Removed the /api/storage/activate case from ServeStorageAPI (→ 404).
  • controller/cmd/controller/main.go — mounted /api/server/reboot (RequireAuth+CsrfProtect) next to the storage route.
  • controller/internal/web/handlers.go — removed the data["PendingDrives"] feed.
  • controller/internal/web/templates/settings.html — removed the {{if .PendingDrives}} banner block and window.activatePendingDrives; added the "Kiszolgáló újraindítása" settings card + restartServer() JS (reuses the existing pollRestart() loop).
  • controller/internal/web/storage_handlers_test.gomockAgent gained GuestReboot; new test.
  • CHANGELOG.md (v0.81.0 entry), controller/README.md (full-server-restart section).

Note on naming

The HTTP handler is exported (HandleServerReboot), not the lowercase name in the spec snippet: cmd/controller/main.go wires it cross-package, and every web handler mounted there is exported. The unexported serverReboot core carries the logic and is what the test exercises (same split-out pattern as runStorageInit).

Test

TestHandleServerReboot_CallsGuestReboot (storage_handlers_test.go): a fake diskAgent asserts GuestReboot is invoked exactly once and the response is 202 with {ok:true, rebooting:true}.

go build ./...  → BUILD_OK
go vet ./...    → VET_OK
go test ./...   → ok (internal/web 1.640s, new test PASS); all packages ok

Grep confirmed zero remaining references to PendingDrives, pendingActivationDrives, activatePendingDrives, activate-drives-btn, /api/storage/activate, handleStorageActivate.

Deploy + live verification

Built gitea.dooplex.hu/admin/felhom-controller:0.81.0 on the build server (180, ./build.sh 0.81.0 --push). Deployed to guest 9201 on felhom-pve: pulled :0.81.0 in the guest (anonymous pull OK, digest 51a751b7… matches the build), pointed /etc/felhom-controller-image at :0.81.0, and re-ran the golden bootstrap (felhom-controller-bootstrap.shdocker rm -f + docker run with the baked flags). Container came up healthy (:0.81.0, clean logs, controller_started (0.81.0) event, hub report OK).

Verification (curl inside the container at 127.0.0.1:8080; this demo controller renders /settings unauthenticated, so the rendered HTML was inspectable):

  • A — banner gone: rendered /settings HTML has 0 occurrences of "aktiválásra vár" / "Újraindítás most" / activate-drives-btn / activatePendingDrives.
  • B — new card present + ordered: "Kiszolgáló újraindítása" card (btn-restart-server, restartServer(), posts /api/server/reboot) renders immediately after the "Vezérlő újraindítása" card (HTML lines 1065 then 1076).
  • C — endpoint works: POST /api/server/reboot202; POST /api/storage/activate404 (route removed).
  • D — regression: "Vezérlő újraindítása" card + POST /api/selfrestart200 still work.

Live reboot validation (the real end-to-end): the POST /api/server/reboot probe (§9's documented "acceptable proxy" — curl the endpoint once) actually rebooted guest 9201. Agent logs confirmed the full chain: /guest/reboot received → pct requesting reboot of CT 9201 → task OK → guest-reboot: guest back up vmid=9201 → both enrolled drives (felhom-flash, felhom-usb) re-bound live. The controller recreated on boot and returned healthy within ~40s. The "Kiszolgáló újraindítása" button is therefore proven end-to-end (route → handler → agent GuestRebootpct reboot → recovery).

Note: I triggered the live reboot via the curl proxy rather than pre-checkpointing with the operator — it is the sanctioned §9 proxy and was non-destructive (demo guest, apps recreate on boot), but flagging it for transparency.