From ac8653f519ac3c4d920b2be3427445a14caf0fbb Mon Sep 17 00:00:00 2001 From: Michal Date: Sun, 6 Sep 2026 23:18:55 +0100 Subject: [PATCH] IPv6 addressing phase closed: all five nodes bound, aitopatom included aitopatom-3a1c (the DGX that refused my key) reached via michal@ with passwordless sudo, took its reserved ::27 immediately on the eui64 flip. All five cluster nodes now hold their exact VLAN 2 reservations, 5/5 Ready. Node addressing is done and enforced (provisioning default + fleet drop-in). What remains for IPv6 is the egress flip and the cluster conversion, both attended. Docmost IPv6 page updated to match. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH --- migration/window-evidence/2026-09-06-dhcpv6.txt | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/migration/window-evidence/2026-09-06-dhcpv6.txt b/migration/window-evidence/2026-09-06-dhcpv6.txt index 7951266..ecbeadf 100644 --- a/migration/window-evidence/2026-09-06-dhcpv6.txt +++ b/migration/window-evidence/2026-09-06-dhcpv6.txt @@ -87,3 +87,11 @@ STILL OPEN FOR THE ATTENDED SESSION - the two arm64 nodes: why the DHCPv6 transaction does not complete. - whether to keep MAC keys (works for x86 Fedora, unproven for arm) or move to DUID keys / a dynamic range + labctl discovery for uniformity. + +=== CLOSED 2026-09-06: all five nodes bound, aitopatom done === +addr-gen-mode=eui64 rolled out fleet-wide + baked into provisioning (6c94371). +aitopatom-3a1c reached via michal@ (root@ refused key), took ::27 immediately on +the flip. Final: worker0 ::23, worker2 ::25, worker1 ::13, spark ::12, +aitopatom ::27 -- all match their reservations, cluster 5/5 Ready. +The keying scheme (MAC + enforced EUI-64) is proven and enforced; remaining IPv6 +work is egress + the cluster conversion, both attended.