# D-057 -- review items for END OF DEPLOYMENT (do not action mid-deploy)

These are real findings surfaced while building the D-057 provider-vip split. None
block the deploy; each is deferred to a post-D-011 reconciliation sweep so we don't
re-architect inside a step. Logged here so they are not lost.

--------------------------------------------------------------------------------
R1. provider-vip-maas-standup.md CREATE blocks are now redundant with the script.
    scripts/provider-vip-standup.sh is the tested execution path for creating the
    plane. The runbook's Phase-2 create blocks duplicate that logic (two sources of
    truth -- this is how the MTU-source bug nearly drifted between them). KEEP the
    runbook for its still-unique parts: Phase-1 audit, the virbr1 vlan_filtering gate,
    and the deferred jumphost-gateway reads. RECONCILE: trim the create blocks to a
    pointer at the script, or annotate them "superseded -- see script". (User: noted
    for end-of-deployment review, not trimmed now.)

--------------------------------------------------------------------------------
R2. scripts/review-bundle.py is STALE (pre-D-052) and is NOT a current gate.
    Run against today's committed bundle it reports ~30 FAILs: its PHANTOM_BINDING_KEYS
    check forbids exactly the per-endpoint bindings (shared-db/amqp/certificates/cluster/
    ha/internal) that D-052 deliberately added, and its VIP check expects DUAL VIPs at
    octets .224-235 in the old 10.12.8 "metal" net -- the bundle has TRIPLE VIPs at
    .50-.60 across provider-public/metal-admin/metal-internal. So review-bundle.py
    predates D-052 entirely and does not describe the live bundle.
    - The "verify_bundle.py / 8/8 harness" referenced in the redeploy notes is NOT at
      this repo HEAD (d575a25) -- only review-bundle.py is.
    - INTERIM GATE for the D-057 change: scripts/d057-bundle-check.py (focused, fail-
      closed, proven FAIL-on-pre / PASS-on-post). It checks only the D-057 invariants.
    - RECONCILE: either bring review-bundle.py forward to D-052/053/D-057 (rewrite
      PHANTOM check, VIP check to triple + provider-vip 10.12.24, octets 50-60), or
      restore/commit the newer verify_bundle.py and retire review-bundle.py.

--------------------------------------------------------------------------------
R3. Committed bundle uses machines 8/9/10/11; the live cloud ran 0/1/2/3.
    Repo-fidelity gap (the committed bundle is not the as-deployed bundle). Does NOT
    affect D-057 (the carve is hostname-based; the MAC trim is by MAC). RECONCILE the
    bundle machine block + `to:` placements to whatever the redeploy actually uses.

--------------------------------------------------------------------------------
R4. oob CIDR -- RESOLVED by D-058. oob adopts 10.12.60.0/22 (the design-docs value).
    The live virsh power gateway 10.12.64.1 -> 10.12.60.1 (scripts/lib-hosts.sh
    VIRSH_POWER_ADDRESS) is part of the D-058 foundation cascade -- see D-058-renumber.md.

--------------------------------------------------------------------------------
R5. gateway_ip default-route watch-item (post-deploy, not end-of-deploy).
    provider-vip subnet carries gateway_ip=10.12.8.1 (post-D-058). This mirrors provider-public's
    existing .4.1 (which already coexists with metal-admin .8.1 without hijacking the
    node default), so risk is low -- but VERIFY after redeploy that every API unit's
    default route is still via metal-admin 10.12.12.1, not .8.1:
        juju exec --all -- ip route show default
    If any unit defaults via .8.1: blank the subnet gateway_ip (set PVIP_GATEWAY="" in
    scripts/provider-vip-standup.sh and re-apply) or pin the node default-gateway subnet
    to metal-admin. provider-vip reachability does not depend on its own gateway in v1.

--------------------------------------------------------------------------------
R6. ovn-chassis-octavia has no bridge-interface-mappings (expected -- it is the
    octavia-side chassis). Left unchanged. Noted only so it is not mistaken for an
    omission during review.