2.0 KiB
FOLLOW-UP — bump the golden's default controller tag + validate the full provision path
Status: OPEN (queued 2026-06-14). Surfaced during the F9/F20 supervised session (agent v0.31.0). Class: provisioning correctness / customer-onboarding. Risk: 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)
- Bump the
build-golden.shdefaultCONTROLLER_IMAGEto the current released controller tag (and establish a convention so it tracks releases — e.g. read aLATEST_CONTROLLERpin, or pass it explicitly from the build pipeline). - 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. - 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).