7c2cbfaf31
Some checks failed
Michal pushed back on "arm64 nodes behave differently" -- correctly. worker2 is aarch64 and binds fine, so architecture was a coincidence. Chased it to the real cause, proven by the kea ALLOC_ENGINE log. The subnet is reservations-only, no dynamic pool. Every node sends DUID-UUID (no MAC), so kea can only match the hw-address reservation by deriving the MAC from the source link-local -- which works ONLY for EUI-64 link-locals. worker0/worker2 have ipv6.addr-gen-mode=eui64; worker1/spark use the default (stable-privacy, RFC 7217), whose link-local embeds no MAC. kea derives nothing, no reservation matches, no pool exists to fall back to: ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS: no pools were available So the "MAC reservation" scheme is really a link-local-EUI-64 scheme, and only works where every node uses EUI-64 link-locals -- not the modern NM default. Fix options (attended) written up in the evidence file: enforce addr-gen-mode=eui64 fleet-wide (smallest, keeps one source of truth), DUID keys, or dynamic pool + discovery. This is the keying decision the plan flagged, now with a precise cause behind it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH