bootnode: lighthouse instead of teku (stable teku fails a Gloas genesis)

[qu0b]

The bootnode's CL was teku (consensys/teku:latest, 26.9.0 stable), inherited from the template. The bootnode is the checkpoint-sync source and serves the CL endpoint for dora, checkpointz and xatu-cannon.

Problem. In kurtosis with this config (Gloas at genesis, frames_enabled), stable teku exits at startup:

FATAL - Teku failed to start: java.lang.IllegalArgumentException: Genesis block root 0x0fbb… does not match genesis state latest block root 0xbebc…

On the devnet it's still only counting down to genesis, so it would fail at 09:00 CEST.

Fix. Run the bootnode on the same pinned ethpandaops/lighthouse:unstable-4b1f3c2 as the validator nodes. That's the only CL tested on this config, so the whole fleet is on one tested build.

• ethereum_node_cl: lighthouse, with validators still disabled.
• Container name, env and volumes follow blob-devnets' lighthouse bootnode. The boot nodes come from the bootnode's CL ENR and the bootnodoor ENR, the same facts the teku config used.
• --archive replaces teku's --data-storage-mode=ARCHIVE, so every state is kept, as xatu-cannon expects.
• The pinned image accepts --testnet-dir, --archive and --boot-nodes; the role adds the execution endpoint.
• ansible-lint (CI command) passes.

An earlier commit on this branch pinned ethpandaops/teku:master-deb3e80, which passed the same kurtosis test. It's reverted in favour of lighthouse.

After merge. Re-run the playbook limited to bootnode-1, so the beacon container switches from teku to lighthouse before genesis.

https://claude.ai/code/session_017oM6BuiHivCb3CXVx2kboG

[redpandabot]

Summary

The head commit swaps the bootnode CL from teku to lighthouse (pinned unstable-4b1f3c2, --archive), replacing the teku pin described in the PR title. Config is consistent with the lighthouse group pattern and the inventory structure imposes no var-precedence hazards. Two concerns: the PR description is stale relative to the actual diff, and the bootnode's lighthouse args omit --allow-insecure-genesis-sync which every other lighthouse host sets.

Issues

• 🟡 ansible/inventories/devnet-0/group_vars/bootnode.yaml — PR description no longer matches the diff — The title and description describe pinning teku to master-deb3e80 (commit 26accff), but head commit 7ffadfe replaces teku with lighthouse entirely, and the 'after merge' instruction still says 'teku restarts on the new image'. Anyone approving/operating from the description gets the wrong change; the description should be updated to match.
• 🟡 ansible/inventories/devnet-0/group_vars/bootnode.yaml:62 — bootnode lighthouse omits --allow-insecure-genesis-sync — Every lighthouse host in group_vars/lighthouse.yaml passes --allow-insecure-genesis-sync; the bootnode's fresh lighthouse datadir (it previously ran teku) starts from ClientGenesis::GenesisState, and lighthouse's builder.rs refuses that start once now > deneb_time + blob-availability window (Gloas at genesis puts Deneb at epoch 0, ~MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epochs). Fine if the restart lands before genesis as planned, but any later first start of the beacon container fails to boot; low risk given the DB-exists path skips the check.

---

_{Reviewed @ 7ffadfe5
Red pandas digest only about a quarter of the bamboo they eat, so they budget energy ruthlessly.}

[qu0b]

Review follow-up:

• 🟡 Stale description: the title and description were rewritten for the lighthouse switch before merge. The review ran against an earlier snapshot.
• 🟡 --allow-insecure-genesis-sync: confirmed in builder.rs:343 at 4b1f3c2. It's added in bootnode: lighthouse --allow-insecure-genesis-sync #4. There's no impact today: the bootnode's datadir already exists and it's waiting for genesis with 6 peers.

https://claude.ai/code/session_017oM6BuiHivCb3CXVx2kboG