# Queued findings -- Stage 5 dc0 Step 7 (phase-03 core verify), 2026-08-06
# Survives-a-clear sweep. Full evidence: docs/audit/stage5-dc0-phase03-coreverify-20260806.txt
# Status authority is CURRENT-STATE.md (section 1 Stage-5 block + section 7 client row).

STEP 7 EXIT GATE: NOT MET (GA-R6/E3, no conditional close). Core-API layer VERIFIED;
two named items keep it OPEN: F-CV3 (Horizon TLS) + Step 3.4 (not run).

--- FINDINGS (logged, NOT fixed -- hard rule 1; operator authorized triage 2026-08-06) ---

F-CV1  designate _admin haproxy backend DOWN. designate/0 apache https frontend binds ONLY
  10.12.8.198:8991 (metal-admin); haproxy's `designate-api_admin_10.12.12.110` backend dials
  10.12.12.110:8991 (METAL-INTERNAL) where apache has no SSL vhost -> check-ssl -> DOWN.
  ROOT CAUSE (researched 2026-08-06, governing = D-052 + the generic binding rule; NOT D-141):
  designate's endpoint bindings deviate from every sibling API app.
   - `:internal` -> metal-internal = CONFIRMED DEFECT (sits on the `''` metal-admin FALLBACK;
     every sibling binds internal->metal-internal; no ruled exception). designate has a
     metal-internal VIP 10.12.12.62 and its cert ALREADY carries the metal-internal SANs, but
     no apache vhost there. FIX (gated, bundle+live per D-072): add `internal: metal-internal`
     to bundle.yaml + `juju bind designate internal=metal-internal`; verify haproxy readback +
     https-200 + re-read cert SANs. All 3 units have metal-internal addrs (no --force needed).
   - `:public` -> provider-public = OPEN, needs operator RULING. designate uniquely has
     prov-pub=1 = `:dnsaas` (D-106 dual-VIP), not `:public`; cert doesn't cover provider-public.
     May be intentional (tenants consume DNS, not the designate REST API). DO NOT assume.
  Section-4 table (network-space-binding-reference.md:88) is "Generated from bundle.yaml"
  (descriptive of the defect), not intent. designate is Stage-7-blocked -> no urgency.

F-CV3  [root cause NOT nailed] dashboard VIP 10.12.4.58:443 serves PLAINTEXT (Horizon exit-gate
  FAILS). Certs present under /etc/apache2/ssl/horizon/; apache :433 served by Ubuntu
  default-ssl.conf, NOT the charm's openstack_https_frontend.conf (glance, working, uses the
  charm frontend w/ SSLEngine on). Charm https frontend not effective for dashboard. SEPARATE
  finding from F-CV1 -- do NOT chase a common fix. Needs focused triage + gated remediation.

  NOTE both: certs ARE present -> NOT the ovn CN-issuance class; NOT a missing certificates
  relation. Charm apache-TLS-frontend layer. Also owed with the Horizon-access remediation:
  D-044 cookie override + D-075 root redirect (per-rebuild, not applied this rebuild).

--- OWED (not findings, just must-not-evaporate) ---

O2  dc1 RACK needs `apt-get install -y python3-openstackclient` (6.6.0-0ubuntu2) BEFORE dc1's
    Step 7 -- F-CV2 is per-DC; only the dc0 rack was done this session (== 07-30 queued-F1).
O4  Step 3.4 keystone domain-manager policy gate (PO: stage-1 + C.4 G3 behavioral, G3 mutates)
    still owed for phase-03 close.
O5  DOCFIX candidate: phase-03-admin-openrc.sh / phase-04-network-{create,verify}.sh /
    phase-04-internal-cert-san-verify.sh / vault-kv-health.sh read DC-dependent lib-net values
    WITHOUT lib_net_select_dc (harmless on dc0, WRONG+SILENT on dc1). Fix before dc1's Step 7.
O6  NAMED-GATE DEFECT (already in CURRENT-STATE): phase-03-core-verify.md Step 3.1 asserts
    non-active/idle == 1; VR1 roster yields the 4 deferred-by-design + gss. Runbook DOCFIX owed
    (-m openstack -> -m vr1-dc0; run-from-rack per D-138; the settle count).
O7  rack kernel 6.8.0-136 running vs 6.8.0-137 available -- reboot NOT taken (would bounce the
    rack + libvirt + all nodes); a maintenance-window item, logged.

--- FIRST SURFACE in this file: F-CV1 (confirmed), F-CV3, O5, O7. ---
