Files
jakman85andClaude Opus 5 c1f24e4a6d fix(dns): resilient node resolvers — mechanism-detecting, per-environment (R-DNS-01/03)
Re-authors the fix stranded on origin/fix/node-dns-resilient-upstream (7a34590). That
commit was NOT landed: it wrote a netplan drop-in and ran `netplan apply`, but netplan
does not exist on these nodes any more (Debian 13 trixie generic cloud image; not in
node_baseline_packages). Landing it would have failed the handler with command-not-found
and BROKEN node-baseline.yml on every node — worse than not landing it. Its dev-LAN
literals also sat in role defaults, which prod inherits, pointing prod nodes at a PiHole
on a network they cannot reach.

The underlying problem is real and verified: a SINGLE upstream resolver is a hard SPOF.
PiHole answers jackson.lan instantly but its external recursion flaps — 0/25 for public
names (registry-1.docker.io, quay.io, ghcr.io) while gitea.jackson.lan resolved 5/5 —
breaking containerd image pulls and CoreDNS `forward . /etc/resolv.conf`.

MECHANISM DETECTION (new `dns` tag in node_baseline). Five read-only probes feed one
set_fact yielding three outcomes, because the two environments no longer share a resolver
stack (dev-1 is behind resolved's 127.0.0.53 stub; prod-1 has a direct resolv.conf and no
cloud-init at all):
  * systemd-resolved — resolved running AND owning /etc/resolv.conf (proven by the
    symlink pointing into /run/systemd/resolve/, or by every nameserver being a resolved
    loopback). Writes resolved.conf.d/99-k3s-dns.conf with an ordered DNS=, Domains=, and
    FallbackDNS= EXPLICITLY EMPTIED so systemd's compiled-in public resolvers can never
    silently bypass the local zone and ad-blocking.
  * resolv-conf-file — plain directly-managed file (prod's shape). Ordered nameserver
    lines + options timeout:2 attempts:2, backup: true. Deliberately NO `rotate`, which
    would destroy PiHole-first ordering.
  * contended — resolvconf/openresolv present or NetworkManager active. Writes NOTHING
    and fails loudly: a change that silently gets reverted is worse than no change.
Resolved-running-but-not-owning-resolv.conf correctly falls through to the file branch.
Ordering is the policy that keeps the local zone working — the second server is only
consulted after the first fails, so a gateway NXDOMAIN can never beat PiHole to a
jackson.lan answer.

SEAMS. Dev values in role defaults ([192.168.1.18, 192.168.1.1], search jackson.lan);
prod values in inventory/group_vars/k3s_prod/vars.yml. NOT cluster-vars — that ConfigMap
is consumed by Flux postBuild for platform/ and apps/, and no Ansible code reads it.

PROD'S SECOND UPSTREAM IS AN OPEN OPERATOR DECISION and is left as a loud
BLOCKED-pending-second-upstream placeholder, the same precedent as the node_baseline disk
devices, with a dns-tagged assert that stops the play before any file is written. A
public resolver was NOT invented as a default: it would bypass the local zone, which is a
decision, not a default. PROD-PROVISIONING.md §4 was rewritten (the old bullet pointed at
the now-dropped branch) to state the choice, including that prod routing to the dev
PiHole is unverified across the pfSense boundary.

tofu: servers = [var.dns_server, var.network_gateway] — the one hunk of the old branch
worth taking as-is. Dev-only by nature.

ALSO FIXES A FALSE WARN THIS WOULD OTHERWISE CREATE: node_health_collect.py parsed
/etc/resolv.conf only, so on dev it read the 127.0.0.53 stub and would report a permanent
single-upstream WARN even after a correct fix. It now asks resolvectl for the real
upstreams when it sees the stub — and if that fails, nameservers is NULL with the reason
recorded, never the stub and never a guess. assess.yml turns null into SKIP, not WARN and
not PASS. The honesty discipline is preserved exactly.

Verified with NO play run against any node: syntax-check + yamllint + tofu fmt clean;
--tags packages still selects ONLY the apt task (the prod package-floor escape hatch
bypasses DNS entirely); --list-hosts unchanged; -c local simulation driving the REAL
detection expression and REAL file bodies extracted from the role by script (so the test
cannot drift) passes all 5 scenarios — dev stub -> systemd-resolved, prod shape ->
resolv-conf-file, NetworkManager and resolvconf -> contended; dev defaults pass the
assert byte-identically while prod overrides fail it by name; collector unit-tested
against 8 resolver shapes.

Serves: R-DNS-01, R-DNS-03, R-ENV-02, R-ENV-03.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-09-01 00:11:49 -05:00
..
2026-08-27 19:53:46 -05:00

infra/tofu — dev/test cluster nodes (OpenTofu + Proxmox VE)

Provisions the "Create" lifecycle stage (docs/02): 3 cloud-init'd VMs on the Proxmox VE box, each with an imported OS disk and a blank Longhorn data disk. (Migrated from the old memory-constrained libvirt host; provider is now bpg/proxmox.)

APPLIED AND LIVE. These three VMs are the running dev cluster — k3s-dev-1/2/3, k3s v1.36.4, carrying the whole platform. Treat any tofu apply/destroy here as an operation on production-for-dev, and note the state file caveat below.

Serves R-ENV-01/02, R-PLAT-01, ADR-0001 (k3s substrate).

What it builds (defaults = the LIVE cluster, verified 2026-08-26)

Resource Value
Proxmox node proxmox
Disk datastore Storage (ZFS, 4.3TB)
Image/snippet datastore local (dir; content = iso + snippets)
Bridge vmbr0 (no VLAN)
Nodes k3s-dev-1/2/3 at 192.168.1.50/.51/.52, gw 192.168.1.1, DNS 192.168.1.18
Per node 6 vCPU, 24 GiB RAM, cpu type host (nested virt for KubeVirt — real KVM confirmed in-guest)
OS disk 64 GiB, virtio0 (/dev/vda, boot), imported from the Debian 13 cloud image
Data disk 128 GiB, virtio1 (/dev/vdb) → /var/lib/longhorn (mounted by cloud-init; Longhorn reports ~125 GiB usable per node)
etcd disk 16 GiB SSD, virtio2 (/dev/vdc) on the local-zfs SSD datastore → etcd data dir (/var/lib/rancher/k3s/server/db); isolates etcd WAL fsync from the HDD Longhorn I/O (docs/plans/ssd-etcd-isolation.md)
Cloud-init native initialization (static IP + DNS) + user-data snippet for the baseline
Reserved 192.168.1.53–.60 for Cilium L2 ingress VIPs (surfaced in outputs). In use: .53 shared Gateway, .54 UniFi

⚠️ State file

terraform.tfstate is gitignored and lives only on the workstation that ran the apply. On a fresh workstation it is absent — and a tofu apply with empty state will try to create three VMs that already exist. Recover the state file (or tofu import the existing VMs) before running anything that plans changes. tofu plan against empty state is itself harmless, but read the plan: "3 to add" means you are missing state, not that the cluster is gone.

All sizing/IPs/counts/placement are variables — see variables.tf.

Files

  • versions.tf — OpenTofu 1.9.0 pin + bpg/proxmox ~> 0.66; provider block with endpoint scheme-normalization (see below).
  • variables.tf — every knob (Proxmox placement, counts, sizing, IPs, image, SSH key).
  • main.tf — cloud image download, per-node user-data snippet, and the 3 VMs.
  • outputs.tf — node IPs/names, primary_node_ip, k3s_api_endpoint, rendered ansible_inventory.
  • terraform.tfvars.example — copy to terraform.tfvars; only ssh_authorized_key required.

Operator prerequisites (before tofu apply)

  1. Enable snippets content on the local datastore. The rich first-boot baseline (users, packages, kernel modules, Longhorn mount, swap-off) is shipped as a cloud-init user-data snippet. In the Proxmox UI: Datacenter → Storage → local → Edit → Content → add Snippets. Without this the proxmox_virtual_environment_file (user-data) resource fails. (Alternatively point image_datastore at any datastore that has snippets enabled.)
  2. Endpoint scheme. If the operator env file exports PROXMOX_VE_ENDPOINT without https://, the provider talks HTTP and eats a 301. Either fix the env file to include the scheme, or export TF_VAR_proxmox_endpoint="$PROXMOX_VE_ENDPOINT" so tofu normalizes it (prepends https://).
  3. pfSense NAT — DONE, live. The workstation reaches the nodes and the kube-API across it: SSH 192.168.2.102:2250/2251/2252 → 192.168.1.50/.51/.52:22, and kube-API 192.168.2.50:6443 → kube-vip VIP 192.168.1.49:6443. infra/ansible/inventory/hosts.ini is hand-maintained for this mapping — do not regenerate it from tofu output -raw ansible_inventory, which knows nothing about the NAT and would overwrite it.

Auth (env only — never in tofu vars/state)

The provider reads these from the environment; the API token is never a tofu variable, so it never enters state, vars, or plan output. You do NOT export these by hand — they live encrypted in secrets.sops.env and the tf.sh wrapper decrypts + exports them (and sets TF_VAR_proxmox_endpoint for scheme normalization) at runtime:

PROXMOX_VE_ENDPOINT=https://192.168.2.102:8006/
PROXMOX_VE_API_TOKEN=user@realm!tokenid=SECRET
PROXMOX_VE_INSECURE=true

See REMOTE-STATE.md for the encrypted-secrets + wrapper flow.

Usage (operator — NOT run here)

All secrets come from the encrypted secrets.sops.env via the tf.sh wrapper, run inside the dev container (which has sops + the age key):

cp infra/tofu/terraform.tfvars.example infra/tofu/terraform.tfvars   # set ssh_authorized_key
./infra/devcontainer/dev.sh run ./infra/tofu/tf.sh init
./infra/devcontainer/dev.sh run ./infra/tofu/tf.sh plan
./infra/devcontainer/dev.sh run ./infra/tofu/tf.sh apply
# hand the node IPs to Ansible:
./infra/devcontainer/dev.sh run ./infra/tofu/tf.sh output -raw ansible_inventory > infra/ansible/inventory/hosts.ini

Hand-off contract

  • primary_node_ip / k3s_api_endpoint (192.168.1.50:6443) is the value the Ansible Cilium bootstrap and the Flux platform/cilium HelmRelease must BOTH use for k8sServiceHost / k8sServicePort (docs/02 parity contract).
  • Destroy/rebuild proof: name-keyed for_each means tofu destroy -target='proxmox_virtual_environment_vm.node["k3s-dev-2"]' then tofu apply re-creates just that node (stop_on_destroy allows the clean stop); Ansible re-joins it; Longhorn replicas reconverge (nodes are cattle).

Static validation (PM, offline)

tofu fmt -check -recursive
tofu init            # fetches the bpg provider (network, read-only)
tofu validate