admin
83ff9e8e38
gates / gates (push) Successful in 16s
GOLDEN_SHA256 39aa886df77b21757aef3b298a389343dc0df5134bb0f14e8f92a451d7bdae87, 656 864 331 B.
The evidence is the ROUND TRIP, not the build log: the published bytes were downloaded back and
match the bake on both size and sha, and ./etc/felhom-controller-image read OUT of the downloaded
archive says felhom-controller:0.229.0 - the delivered artifact naming the controller it will start.
A THIRD independent reader agreed before anything was vouched: the hub's own Day-0 dropdown read the
same sha straight from Gitea, a different code path.
Both pre-gates were proven able to see something before their negative results were believed - the
404 pre-gate against a 200 from 0.228.0, and the token-leak grep against a seeded throwaway copy.
Acceptance markers counted on the COMMITTED log: 1/1/1/1 present, 0/0/0 absent.
The vouch is a three-field change, checked rather than assumed: MinAgent 0.129.0 read from the
golden's controller CHANGELOG header, agent_version 0.130.0 >= min_agent 0.129.0 (not the R-216
shape), agent_sha256 and wrapper_sha256 carried through explicitly because the handler clears a
field it is not sent. Verified by re-reading the manifest, never by trusting the flash. The R-120
gate PASSED rather than being bypassed - fleet newest 0.229.0, golden 0.229.0.
The floor is proven ACTING, not merely set: demo-felhom self-updated 0.228.0 -> 0.229.0 and logged
settle-gate GO at/above floor 0.229.0. Nobody deployed to that box. Both demo machines now carry the
Tier-2 unit restore.
golden_currency_gate.py went red -> green; the --no-verify bypass declared on c2de785 is now
historical. R-242's other half is untouched and still open: nothing gates the VOUCH itself.
Teardown: build guest 9100 destroyed --purge, token/runner/script/log shredded AFTER the log was
copied out, VM powered off, qemu confirmed gone from ps -eo comm, disk reverted to virgin.
130 lines
6.1 KiB
Markdown
130 lines
6.1 KiB
Markdown
# Golden bake 0.229.0 — 2026-08-31
|
|
|
|
Baked, published, round-trip verified, **vouched**, and the fleet floor raised. `demo-felhom` picked
|
|
up the new controller **by itself**, unattended.
|
|
|
|
## What was produced
|
|
|
|
| | |
|
|
|---|---|
|
|
| `GOLDEN_VERSION` | **0.229.0** |
|
|
| `GOLDEN_SHA256` | `39aa886df77b21757aef3b298a389343dc0df5134bb0f14e8f92a451d7bdae87` |
|
|
| size | **656 864 331 B** |
|
|
| package URL | `…/api/packages/admin/generic/felhom-golden/0.229.0/golden.tar.zst` |
|
|
| baked controller | `gitea.dooplex.hu/admin/felhom-controller:0.229.0` |
|
|
| `MinAgent` | **0.129.0** — read from the controller `CHANGELOG.md` header, not assumed |
|
|
| script | `build-golden.sh v3.0.0`, sha256 `7b0fb5cf…73b6a1` — **compared across the hop**, identical on DooPlex and inside the VM |
|
|
| venue | the drill VM on DooPlex, reverted to `virgin` and **cold-booted** first |
|
|
| template | `debian-13-standard_13.6-1_amd64.tar.zst`, after `pveam update` (the virgin snapshot's INDEX is stale too, and the failure reads as a bogus `400 no such template`) |
|
|
| archive volid | `local:backup/vzdump-lxc-9100-2026_08_31-12_30_37.tar.zst` |
|
|
|
|
## Acceptance markers — counted on the COMMITTED log, not eyeballed
|
|
|
|
```
|
|
docker OK (overlay2 : 1
|
|
including mount point rootfs : 1
|
|
including mount point mp0 : 1
|
|
upload OK (HTTP 201) : 1
|
|
--- must be ZERO ---
|
|
excluding : 0
|
|
FATAL : 0
|
|
mount point mp1 : 0 ← mp1 stopped existing in build-golden.sh v3.0.0 (R-165)
|
|
```
|
|
|
|
`felhom-controller:0.229.0` appears **4** times in the bake log.
|
|
|
|
**The 404 pre-gate was PROVEN TO WORK before its 404 was believed.** The target URL returned `404`
|
|
and, on the same command, the existing `0.228.0` package returned `200` — a positive control, because
|
|
a `404` from a check that cannot see anything is not a measurement. The script's own pre-delete then
|
|
reported `HTTP 404 (404/204 expected)`: nothing was overwritten.
|
|
|
|
## The evidence is the ROUND TRIP, not the build log
|
|
|
|
```
|
|
downloaded size : 656864331 bake reported : 656864331
|
|
downloaded sha : 39aa886d…d7bdae87 bake reported : 39aa886d…d7bdae87
|
|
```
|
|
|
|
**And the delivered artifact was asked what it will start** — `./etc/felhom-controller-image` read
|
|
*out of the downloaded archive*:
|
|
|
|
```
|
|
gitea.dooplex.hu/admin/felhom-controller:0.229.0
|
|
```
|
|
|
|
That is the golden naming the controller it will run, read from the bytes a customer's box would
|
|
actually fetch — not from the build host, and not from the local file.
|
|
|
|
**A third, independent reader agreed.** The hub's own Day-0 dropdown read
|
|
`data-sha="39aa886df77b21757aef3b298a389343dc0df5134bb0f14e8f92a451d7bdae87"` for 0.229.0 straight
|
|
from Gitea, before anything was vouched — same sha, different reader, different code path.
|
|
|
|
## The vouch — three fields, all checked
|
|
|
|
| field | value | why it is right |
|
|
|---|---|---|
|
|
| `golden_version` | 0.229.0 | baked and round-trip verified above |
|
|
| `agent_version` | 0.130.0 | published, unchanged, and **≥ `min_agent`** |
|
|
| `min_agent` | 0.129.0 | read from the golden's controller CHANGELOG header |
|
|
|
|
`agent_version (0.130.0) ≥ min_agent (0.129.0)` — **not the R-216 shape**, where a floor points above
|
|
the agent it is served with. `agent_sha256` and `wrapper_sha256` were carried through **explicitly**,
|
|
because the handler clears a field it is not sent. **Verified by RE-READING the manifest, not by
|
|
trusting the flash** (`303 → ?flash=artifacts_set`):
|
|
|
|
```
|
|
agent_version 0.130.0 SELECTED sha=a56a92a7…eaefabc3
|
|
golden_version 0.229.0 SELECTED sha=39aa886d…d7bdae87
|
|
agent_sha256 a56a92a7bd68f5b46736eaec4806c3d26c16ccb35118c4ac0e3d8094eaefabc3
|
|
golden_sha256 39aa886df77b21757aef3b298a389343dc0df5134bb0f14e8f92a451d7bdae87
|
|
min_agent 0.129.0
|
|
wrapper_sha256 104db0a4401f65bbc476e82bfb1796433bcb36f8f8cce69efb3bb5c40fcb16b3
|
|
```
|
|
|
|
The **R-120 gate** on this POST refuses a golden below the newest controller the fleet reports; fleet
|
|
newest was 0.229.0 and the golden is 0.229.0, so it **passed rather than being bypassed** — a refusal
|
|
would have redirected to `?flash=golden_behind_fleet` and written nothing.
|
|
|
|
## The floor is ACTING, not merely set
|
|
|
|
Blast radius before the change: `{"below":3,"valid":true,"version":"0.229.0"}`.
|
|
Re-read after (not the flash): `min_controller_version value="0.229.0"`, `Effective floor v0.229.0`,
|
|
`DB override: v0.229.0`.
|
|
|
|
**`demo-felhom` self-updated and re-registered its jobs by itself:**
|
|
|
|
```
|
|
[INFO] [selfupdate] Post-update startup: update successful (0.228.0 → 0.229.0)
|
|
[INFO] [scheduler] Registered periodic job: selfupdate-check (every 6h0m0s)
|
|
[INFO] [offsite-apply] settle-gate: GO — at/above floor 0.229.0 (we are 0.229.0), no managed update running
|
|
```
|
|
|
|
**Nobody deployed to that box.** Only `demo-hp` was ever touched by hand. Both demo machines are now
|
|
on 0.229.0, so **both carry the Tier-2 unit restore** (R-102/R-103) — which is the point of this
|
|
release reaching the fleet, observed rather than assumed.
|
|
|
|
`golden_currency_gate.py` went **red → green** on this bake being recorded, which is its proof that it
|
|
measures something real.
|
|
|
|
## Token hygiene
|
|
|
|
Copied **file → file** (`scp`), never crossing a shell on either side; the bake ran through a runner
|
|
script inside the VM that reads the token itself, so it never reached a command line or a transient
|
|
unit's properties:
|
|
|
|
```
|
|
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)" → 0
|
|
```
|
|
|
|
**The leak grep on the committed log was PROVEN TO WORK before its `0` was believed** — a throwaway
|
|
copy with the token appended grepped **1**, was `shred -u`'d, and only then was the real log's **0**
|
|
taken as evidence. A `0` from an untested grep is not a measurement.
|
|
|
|
## Teardown
|
|
|
|
Build guest `9100` destroyed `--purge` (`pct list` then empty); token, runner script, bake script and
|
|
log `shred -u`'d **after** the log was copied out (standing rule 5); VM powered off, qemu confirmed
|
|
gone from `ps -eo comm` (never `pgrep -f`, which self-matches), disk reverted to `virgin`, pidfile
|
|
removed, `/root` left holding only its stock dotfiles. Nothing else provisioned: no hub record, no
|
|
host record, no storage entry.
|