From 08fbe856388d0dd27c34c0e2d9ed89c3bdc69dac Mon Sep 17 00:00:00 2001 From: Keith Jackson Date: Mon, 7 Sep 2026 21:41:54 -0500 Subject: [PATCH] fix(ansible): move the founder designation to node 2 Node 1's SSD failed and was replaced; Debian was reinstalled, so node 1 is now a JOINING node with no cluster state. It was still listed in [k3s_prod_primary], and that group decides two things at once: 1. which play gets k3s_server_mode: primary -> --cluster-init, which FOUNDS A NEW CLUSTER, and 2. what k3s_api_host resolves to -- the --server join target. So re-provisioning node 1 unchanged would have pointed a rebuilt, empty node at ITSELF and founded a second cluster beside the live one. The role's `creates: /etc/rancher/k3s/k3s.yaml` guard does not help: on a fresh install that file is absent, so cluster-init WOULD have run. Node 2 is the senior surviving server (up since 2026-09-01) and takes the founder slot. Its own cluster-init task is inert precisely because k3s.yaml already exists there. Verified after the change: k3s_api_host renders 192.168.2.11, and groups[k3s_primary_group][0] is k3s-prod-2. This is a latent gap the role documented but did not handle -- its comment assumes the founder is always alive ('On a WARM single-node rejoin the founder is up and answering too'). Rebuilding the founder itself was not covered. Co-Authored-By: Claude Opus 5 --- infra/ansible/inventory/hosts.ini | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/infra/ansible/inventory/hosts.ini b/infra/ansible/inventory/hosts.ini index e726ec4..1d0f330 100644 --- a/infra/ansible/inventory/hosts.ini +++ b/infra/ansible/inventory/hosts.ini @@ -92,9 +92,17 @@ proxmox ansible_host=192.168.2.102 ansible_port=22 ansible_user=root ansible_ssh # ============================================================================= [k3s_prod_primary] -k3s-prod-1 ansible_host=192.168.2.10 ansible_port=22 k3s_node_ip=192.168.2.10 +# FOUNDER MOVED TO NODE 2 (2026-09-07). Node 1 founded this cluster with --cluster-init, +# then its SSD was replaced and Debian reinstalled, so it is now a JOINING node like any +# other. This group decides two things at once: which play sets k3s_server_mode: primary +# (-> --cluster-init, which FOUNDS A NEW CLUSTER) and what k3s_api_host resolves to (the +# --server join target). Leaving node 1 here would have pointed a rebuilt, empty node at +# ITSELF and founded a second cluster beside the live one. Node 2 is the senior surviving +# server; its own --cluster-init is inert because /etc/rancher/k3s/k3s.yaml already exists. +k3s-prod-2 ansible_host=192.168.2.11 ansible_port=22 k3s_node_ip=192.168.2.11 [k3s_prod_secondary] +k3s-prod-1 ansible_host=192.168.2.10 ansible_port=22 k3s_node_ip=192.168.2.10 # Uncomment a node only once it is actually on the bench and answering SSH, so no play can # target a host that isn't there. k3s-prod-2 came online 2026-09-01 (imaged identically to # node 1: same HP EliteDesk 800 G5 Mini, same BIOS R21 02.26.00, same i7-9700T, same @@ -110,7 +118,6 @@ k3s-prod-1 ansible_host=192.168.2.10 ansible_port=22 k3s_node_ip=192.168.2.10 # three-way, not a node-1 outlier. # NOTE: node 3 also has wlp1s0 up on 192.168.2.195 (wifi). `ansible_host` is deliberately # the WIRED eno1 address — the same directly-routable 192.168.2.x LAN as nodes 1 and 2. -k3s-prod-2 ansible_host=192.168.2.11 ansible_port=22 k3s_node_ip=192.168.2.11 k3s-prod-3 ansible_host=192.168.2.12 ansible_port=22 k3s_node_ip=192.168.2.12 # Umbrella group group_vars/k3s_prod/ attaches to (mirrors dev's [k3s_servers:children]