felhom.eu/documentation/backlog/FOLLOWUP-golden-default-controller-tag.md

FOLLOW-UP — bump the golden's default controller tag + validate the full provision path

Status: RESOLVED 2026-07-03 — build-golden.sh v2.0.0 (felhom-agent @ ceca355) makes the controller tag a MANDATORY argument (the hand-bumped default had rotted AGAIN, 0.43.0 → 0.85.1 → stale vs 0.98.3 — a required arg cannot rot); golden 0.98.3 baked + validated clean-room on the drill VM (first boot lands the current controller, self-update reports up-to-date, app deploys) + published + operator-vouched. The full first-boot path was validated WITHOUT a supervised destroy→re-provision (drill VM virgin snapshot instead — nothing touched 9201/felhom-pve). Evidence: ../audits/DRILL-golden-098-2026-07-03.md. Item 3 (provision re-asserting user-data binds) was shipped separately (agent-startup re-assert + F9 part A). Original note kept below for history. Class: provisioning correctness / customer-onboarding. Risk (as queued): SUPERVISED (golden + a real destroy→provision).

The problem

felhom-agent/configs/build-golden.sh:43 bakes the controller image into the golden as:

CONTROLLER_IMAGE="${6:-gitea.dooplex.hu/admin/felhom-controller:0.43.0}"

:0.43.0 is ~20 versions stale (current is 0.63.0). The bootstrap writes it to /etc/felhom-controller-image and docker runs that tag on first boot. So the next time a golden is actually baked for a real provision, it would stand a customer guest up on an ancient controller — missing every fix since 0.43.0 (incl. F1 memory guard, F17 DB restore, the M18/M19 fixes, etc.). It only hasn't bitten because the running demo guest 9201 had its /etc/felhom-controller-image updated in place post-provision; a fresh provision would not.

This is why the F9 session chose attach-to-existing over destroy+re-provision (a re-provision would have regressed 9201's controller 0.62.0 → 0.43.0).

The fix (separate task)

1. Bump the build-golden.sh default CONTROLLER_IMAGE to the current released controller tag (and establish a convention so it tracks releases — e.g. read a LATEST_CONTROLLER pin, or pass it explicitly from the build pipeline).
2. Validate the full path end-to-end, which does warrant a supervised destroy + re-provision (it is the real customer-onboarding flow, not coverable by attach-to-existing): bake golden → provision a scratch guest → first boot stands up the current controller → controller ONLINE on the hub → enrolled user-data drive is bound (F9 ReassertGuestBinds / provision bind) → an app deploys.
3. While there: confirm the provision path itself asserts known user-data binds (F9 part A for the re-provision case, complementing the agent-startup re-assert already shipped in v0.31.0).