Revert "feat(dns): INVERT to operator's simpler layout — dev to subdomain, prod to apex"

This reverts commit 9137bbd0c3.
2026-09-06 20:27:41 -05:00
1 parent 6f61c9622d
commit f341a9b744
@@ -306,47 +306,35 @@ node_baseline_dns_servers:
  # k3s_base_domain, below). It reaches the issuer through the NODE resolver, i.e. through
  # these PUBLIC upstreams — not through CoreDNS's split-horizon answer.
  #
-  # ORDERING HAZARD, NOT YET CLEARED. Prod's issuer is keycloak.home.keithjackson.dev — an APEX
-  # name, because prod IS the apex under the 2026-09-04 inversion (k3s_base_domain below).
-  # That is the name the LIVE DEV CLUSTER answers today, and its public A record currently
-  # points at DEV's Gateway VIP (192.168.1.53) — the wrong cluster, on the wrong LAN. A prod
-  # node resolving its own issuer through these public upstreams therefore reaches dev until:
-  #   (1) dev has migrated to *.dev.home.keithjackson.dev and RETIRED its apex records, and
-  #   (2) PROD's own external-dns has published keycloak.home.keithjackson.dev at PROD's
-  #       Gateway VIP (192.168.2.20).
-  # Only then do the public answer and the in-cluster split-horizon answer AGREE, and no
-  # /etc/hosts pin is needed. Until then kubectl OIDC SSO on prod cannot work; the cert-based
-  # admin kubeconfig is the break-glass path and always works. Ordering, not a design gap —
-  # the ordered steps are infra/PROD-PROVISIONING.md §10.
+  # THIS USED TO BE BROKEN, AND THE 2026-09-04 SUBDOMAIN SPLIT FIXED IT. While prod was
+  # authored to serve dev's hostnames, a prod node resolving keycloak.home.keithjackson.dev
+  # publicly got DEV's Gateway VIP (192.168.1.53) — the wrong cluster, on the wrong LAN, so
+  # kubectl OIDC SSO on prod could not work at all. Now prod's issuer is
+  # keycloak.prod.home.keithjackson.dev, and the public record for that name is published by
+  # PROD's own external-dns pointing at PROD's Gateway VIP (192.168.2.20). The public answer
+  # and the split-horizon answer therefore AGREE, and no /etc/hosts pin is needed.
+  #
+  # STILL TO VERIFY on prod bring-up (PROD-PROVISIONING.md §10): this holds only once prod's
+  # external-dns has actually published the record. Until then the issuer does not resolve
+  # from the nodes and kubectl SSO fails — the cert-based admin kubeconfig is the break-glass
+  # path, and it always works. Ordering, not a design gap.
 node_baseline_dns_search: []

 # --- platform hostname suffix, ANSIBLE SIDE (R-ENV-02, R-DNS-01) --------------------
-# PROD **IS** THE APEX. [parity] MUST equal BASE_DOMAIN in clusters/prod/kustomization.yaml —
-# the same one-fact-in-two-places contract as k3s_data_dir and k3s_api_host. The Flux side
-# cannot supply this: the kube-apiserver's oidc-issuer-url is a k3s server FLAG written to
-# /etc/rancher/k3s/config.yaml, not a manifest, so postBuild.substituteFrom never sees it.
-# Full rationale in roles/k3s_server/defaults/main.yml, where k3s_oidc_issuer_url derives.
+# PROD SERVES ITS OWN SUBDOMAIN. [parity] MUST equal BASE_DOMAIN in clusters/prod/
+# kustomization.yaml — the same one-fact-in-two-places contract as k3s_data_dir and
+# k3s_api_host. The Flux side cannot supply this: the kube-apiserver's oidc-issuer-url is a
+# k3s server FLAG written to /etc/rancher/k3s/config.yaml, not a manifest, so
+# postBuild.substituteFrom never sees it. Full rationale in
+# roles/k3s_server/defaults/main.yml, where k3s_oidc_issuer_url is derived from this.
 #
-# WHY THE SUFFIXES SPLIT (infra/PROD-PROVISIONING.md §10): both clusters were authored to serve
-# the SAME hostnames from the SAME Cloudflare zone, and on 2026-09-04 prod's external-dns
-# deleted every one of dev's public records.
-#
-# WHICH WAY ROUND — INVERTED 2026-09-04 by operator decision, superseding the interim split
-# committed earlier the same day (prod on `prod.home.` behind apex CNAMEs). The simpler target:
-#   prod -> home.keithjackson.dev       (THE APEX; this variable — no `prod.` label, no CNAMEs)
-#   dev  -> dev.home.keithjackson.dev   (roles/k3s_server/defaults/main.yml)
-# So prod's Keycloak issuer is https://keycloak.home.keithjackson.dev/realms/homelab, and the
-# `kubernetes` OIDC client in PROD's OWN Keycloak realm is what prod's kubectl SSO authenticates
-# against.
-#
-# ORDERING HAZARD SPECIFIC TO THIS VARIABLE. keycloak.home.keithjackson.dev is the name the LIVE
-# dev cluster answers today, and prod's nodes resolve the issuer through PUBLIC upstreams (see
-# node_baseline_dns_search above). So until dev has vacated the apex and PROD's external-dns has
-# published that name at PROD's Gateway VIP (192.168.2.20), a prod node resolving its own issuer
-# gets DEV's VIP (192.168.1.53) — the wrong cluster, on the wrong LAN. kubectl OIDC SSO on prod
-# therefore does not work until §10's dev-vacate steps are complete; the cert-based admin
-# kubeconfig is the break-glass path and always works. Ordering, not a design gap.
-k3s_base_domain: "home.keithjackson.dev"
+# WHY PROD MOVED (infra/PROD-PROVISIONING.md §10): both clusters were authored to serve the
+# SAME hostnames from the SAME Cloudflare zone, and on 2026-09-04 prod's external-dns
+# deleted every one of dev's public records. Dev stays on home.keithjackson.dev (it is LIVE);
+# prod takes prod.home.keithjackson.dev. Consequence here: prod's Keycloak issuer is
+# https://keycloak.prod.home.keithjackson.dev/realms/homelab, so the `kubernetes` OIDC client
+# in prod's OWN Keycloak realm is what prod's kubectl SSO authenticates against.
+k3s_base_domain: "prod.home.keithjackson.dev"

 # --- Flux bootstrap: WHICH overlay this environment reconciles from (R-ENV-02) -----
 # roles/flux_bootstrap defaults flux_bootstrap_env_path to `clusters/dev` (dev is LIVE
@@ -95,26 +95,15 @@ k3s_tls_sans: >-
 # while the cert-based admin kubeconfig keeps working — so it looks like "SSO is broken",
 # not like a config skew. The break-glass cert kubeconfig is why this is recoverable.
 #
-# THE DEFAULT IS THE DEV VALUE — the same convention as k3s_data_dir above and cluster-vars'
-# GATEWAY_VIP / LONGHORN_DATA_PATH: the role default is dev's value and prod overrides it in
-# inventory/group_vars/k3s_prod/vars.yml (the same inventory seam k3s_data_dir / k3s_api_host /
-# kube_vip_address use, so a FOURTH prod server inherits it from group membership rather than
-# from anyone remembering).
+# THE DEFAULT IS THE DEV VALUE, restated explicitly rather than left implicit — the same
+# convention as k3s_data_dir above and cluster-vars' GATEWAY_VIP / LONGHORN_DATA_PATH: the
+# base default is the known-good LIVE value, so dev's rendered config.yaml is byte-for-byte
+# what it already is and the Restart handler does NOT fire on a re-run.
 #
-# *** WHICH DEV VALUE — UPDATED 2026-09-04, AND IT IS AHEAD OF THE LIVE DEV CLUSTER. ***
-# The operator inverted the suffix split: PROD is now the apex `home.keithjackson.dev` and DEV
-# carries the label `dev.home.keithjackson.dev`. This default therefore moved from the apex to
-# dev's subdomain, mirroring BASE_DOMAIN in clusters/dev/kustomization.yaml.
-#
-# CONSEQUENCE — this default no longer matches what the live dev nodes are running, so unlike
-# every previous edit to this file A DEV RE-RUN IS NOT A NO-OP. Rendering config.yaml with the
-# new issuer CHANGES the file, FIRES the Restart handler, and rolls k3s on all three dev
-# servers, which also invalidates every user's OIDC kubeconfig (SSO must be re-issued). That is
-# a deliberate step of the dev DNS migration, NOT a side effect to discover during unrelated
-# work: DO NOT run the k3s_server role against dev until step D6 of
-# infra/PROD-PROVISIONING.md §10, and never while the operator is away. The break-glass
-# cert-based admin kubeconfig keeps working throughout, which is what makes the step safe.
-k3s_base_domain: "dev.home.keithjackson.dev"
+# PROD OVERRIDES IT in inventory/group_vars/k3s_prod/vars.yml — the same inventory seam
+# k3s_data_dir / k3s_api_host / kube_vip_address use, so a FOURTH prod server inherits it
+# from group membership rather than from anyone remembering.
+k3s_base_domain: "home.keithjackson.dev"

 # Derived, so the realm path is stated once. Override k3s_base_domain, not this.
 k3s_oidc_issuer_url: "https://keycloak.{{ k3s_base_domain }}/realms/homelab"