Newer
Older
openstack-caracal-dc-dc / docs / audit / container-elim-pass / FINAL-advisor-review.md

FINAL advisor review -- container-layer-elimination pass (aggregate)

Reviewer: the advisor (advisor() tool; recorded as "the advisor" -- no model name asserted, per operator instruction). Date: 2026-08-09. Input: the full pass transcript (all worker bounded summaries, the five administrator reports, FINAL-PLAN.md).

Verdict: SOUND

Nothing in the aggregate overturns the pass's three load-bearing conclusions:

  • Option 1 (flat node VMs on vcloud libvirt + a small per-DC vr1-dcN-client VM) as the target;
  • Root topology (B) (shared-outer + per-DC-flat roots) as the recommended tofu shape;
  • New D-144 (superseding D-123 Model B) as the decision form, with the D-143 precedent.

The plan is honest about its open items and its recommendation-grade items pending live re-measure. The advisor raised TWO follow-up gaps -- both the SAME failure shape (an attachment object is deleted; a survivor is glossed "unchanged" when its attachment point no longer exists). Both were VERIFIED against the full pass docs by the orchestrator this session. Neither changes the plan's direction; each becomes a NAMED open item.

Follow-up 1 -- MAAS power-dial REACH (distinct from authorization scope). CONFIRMED, fold into DEC-15.

The pass covered the power-key AUTHORIZATION concern thoroughly (both DCs' region VMs dial one vcloud qemu:///system; the #11 mitigation / DEC-15 scopes it). It did NOT resolve REACHABILITY: how an in-plane vr1-dcN-maas-01 gets an L3 path to vcloud's own libvirtd at all. Model B dialed the containment VM at an in-plane metal-admin address (10.12.x.2); flat, the target is vcloud's own libvirtd, and vcloud by design holds no address on any DC plane. The naive fix -- give vcloud an address on the metal-admin bridge -- is EXACTLY "a host address on a plane bridge", which W3.3's (a)-control fixture treats as a failure-to-catch. Evidence: pass2-w3-scripts.md:184-201 and pass4-w3 B.6.1/B.6.2 assume "one endpoint reachable from BOTH DCs' region VMs" without spelling out the reach path. Disposition: DEC-15's framing is AMENDED -- the power-key mechanism ruling must decide REACH and AUTHORIZATION together (the reach path and the (a) control's no-host-on-plane-bridge rule must be reconciled, not left to a delivery-time improvisation). Does not block the D-144 package; sharpens DEC-15.

Follow-up 2 -- the dc0<->dc1 mesh leg's post-flatten consumer + cross-DC Ceph path. CONFIRMED, NEW open item DEC-24.

Verified precisely: the containment VMs attach ONLY to the two Office1-TRANSIT mesh legs (opentofu/main.tf:192-193 region-end, :430/:554-555 DC-end) -- which the pass reassigns cleanly to the vr1-dcN-client VM's transit NIC (pass2-w1-tofu-modules.md row mesh-link; pass4-w3 B.1.4). But the dc0<->dc1 leg is a DIFFERENT segment: bridge virbr5 (main.tf:356), the netem target (main.tf:334-356), designed as the cross-DC Ceph replication carrier (D-100 mesh-not-star rationale design-decisions.md:2235; D-108 rbd-mirror/radosgw-multisite rides the IPv6 replication plane :3051; dc0<->dc1 stays replication-only :4993). pass2-w1 graded it "untouched either way" -- true for the BRIDGE's existence, but it does NOT define what attaches the (now vcloud-level) replication plane to virbr5 and routes cross-DC traffic THROUGH netem once the containment layer is gone. Disposition: NEW open design item DEC-24 (Tier 1-adjacent, pairs with DEC-14 the (a)-control): "who holds the dc0<->dc1 mesh-leg endpoints and how does the flat-topology replication plane route cross-DC Ceph traffic through netem (WAN fidelity) without violating the (a) control." Nuance carried honestly: this is PARTLY pre-existing -- cross-DC replication was never built (dc1 HELD, rbd-mirror blocked), so the flat design must DEFINE this path, it is not a regression the flattening introduces into a working path. Roosevelt-delta: on bare metal the dark-fiber dc0<->dc1 leg is real (design-decisions.md:2235), so this routing must be defined regardless -- the flat rehearsal is the right place to design it.

Report mechanics (advisor-directed, executed by the orchestrator)

  1. This file (FINAL-advisor-review.md) captures the review. [done]
  2. operator-report.md leads with the Tier-1 decisions (DEC-01 first; DEC-15 as the sharpest execution blocker, now carrying the reach dimension; DEC-24 added), carries W4.4's evidence-grounded ledger verbs (D-122 AMENDS, D-127 AMENDS-deferred -- NOT the tasking shorthand), and marks the recommendation-grade items (DEC-08/09 rack retirement, FIT/capacity) as pending live re-measure. It situates Part A: the teardown presumes the dc0 checkpoint wrap-gates (cloud-assert BOM, controller backup, verify-live Ceph) close first -- still owed per the ledger.
  3. Durability: commit + push the pass folder; repo-lint first (24 worker-authored docs risk non-ASCII); update CURRENT-STATE's "CONTAINER-ELIM PASS SCOPED ... NOT YET RUN" line to point at FINAL-PLAN.md + operator-report.md IN THE SAME COMMIT (GA-R1 C1). The full session bookend (savegame) stays the operator's call.