STAGE 5 -- dc0 bundle deploy ATTEMPT 3 (2026-07-31): SUCCEEDED
==============================================================

>>> VERDICT: `Deploy of bundle completed.`  EXIT 0 <<<

COMMAND (from the dc0 rack, D-138 client host, cwd ~/repo-stage):
  juju deploy ./bundle.yaml --overlay ./overlays/vr1-dc0-vips.yaml \
    --overlay ./overlays/vr1-dc0-machines.yaml \
    --overlay ./overlays/vr1-dc0-octavia-pki.yaml -m vr1-dc0

MEASURED IMMEDIATELY AFTER
  juju    56 applications, 9 machines, 33 units
          machine juju-status  : 9 x pending
          machine instance-stat: 9 x allocating
  MAAS    10 machines: 9 Deploying, 1 Deployed (the juju controller, already up)

WHAT MADE THIS ATTEMPT DIFFERENT -- three defects closed, in the order they were hit
------------------------------------------------------------------------------------
  attempt 1  `unknown option "prefer-ipv6"` on barbican. Aborted at VALIDATION, model
             left empty. CLOSED by the D-101 RULING NOTE 2026-07-31: the six charms that
             do not declare the option no longer receive it, and every v6 VIP leg is
             retained -- the option was never what made HAProxy bind `:::port`.
  attempt 2a `file for resource "policyd-override": stat .../policies/overrides.zip: no
             such file or directory`. Reached EXECUTION and left 23 application
             definitions. CLOSED by staging `policies/` on the rack, sha256-verified.
  attempt 2b `barbican: downgrades are not currently supported: deployed revision 265 is
             newer than requested revision 261`. CLOSED by RULING 2026-07-31 (option D):
             an explicit `base: ubuntu@22.04/stable` on all 56 applications, plus
             clearing the model so the deploy runs the path that is MEASURED to work.

THE PRE-DEPLOY SEQUENCE, all of it verified rather than assumed
---------------------------------------------------------------
  1. bundle fixed: 56/56 applications carry an explicit base; the edit was cross-checked
     against `yaml.safe_load` (a first pass silently covered 44 of 56 -- the twelve
     `-hacluster` apps are single-line FLOW MAPPINGS) and asserted on the ARTIFACT (the
     parsed structures with `base` stripped are IDENTICAL to the original).
  2. gated: `provider-bundle-check` invariant 12 is NEW and mutation-proven five ways, so
     the 56 lines cannot be silently simplified away. It caught a real gap on its FIRST
     run -- `overlays/dc-ha-scaleup.yaml` DEFINES `vault-hacluster`, an application in no
     other file, and it had no base. That is a LATER deploy step, so the trap would have
     re-opened after this deploy succeeded.
  3. proven: the fully-based bundle `--dry-run` against the LIVE 23-app model exited 0,
     where the unbased one errored. The one-app test before it was an INFERENCE; this is
     the measurement.
  4. deploy input staged on the rack and ALL FIVE files sha256-compared to repo HEAD:
     bundle.yaml 4c8a7852, vr1-dc0-vips daa2919d, vr1-dc0-machines b70e4eed,
     policies/overrides.zip 02fe1fd7, and the gitignored vr1-dc0-octavia-pki 5fc117f1
     (0600, SEC-029 custody untouched).
  5. model CLEARED: all 23 application definitions removed INDIVIDUALLY, never batched
     (hard rule 3), each read back; precondition re-verified immediately before the first
     removal (0 units, 0 machines, nothing provisioned). Read-back after: `Model
     "vr1-dc0" is empty`, 0 applications / 0 machines.
  6. Step-3.5 model state confirmed to have SURVIVED the clear: `apt-mirror
     http://10.12.8.4/ubuntu` still set, all six spaces still bound with their v4 and v6
     subnets.
  7. preflight P1-P4 + P7 PASS; P5 RED with 11 findings, ALL ELEVEN ruled-accepted
     (six 2026-07-30, five 2026-07-31), enumerated in
     docs/audit/stage5-preflight-dc0-20260731.txt.

NOTES CARRIED FORWARD
---------------------
  - `juju remove-application` PROMPTS by default and aborts on a non-interactive stdin
    (`ERROR application removal: aborted`, exit 1). `--no-prompt` is required from a
    non-interactive session. Recorded because the first removal read as a failure.
  - `ceph-osd`'s `tags=openstack` constraint (bundle.yaml) is still the known exposure and
    is still NOT a problem for this deploy: placement is by explicit machine id
    (`ceph-osd/0..3` -> machines 5,6,7,8). A later UNPLACED `juju add-unit ceph-osd` would
    match no machine. LOGGED, unchanged.
  - **G17's dc0 half is now genuinely armable.** The existing capture was taken on the
    CONTROLLER VM, not a role node, and said so. The nine role nodes are booting for the
    first time as this file is written -- that is G17's window.

WHAT IS NOT CLAIMED
-------------------
`Deploy of bundle completed.` means juju ACCEPTED and queued the bundle. It does NOT mean
the cloud is up. 9 machines are allocating, 33 units are pending, and the settle to
phase-01's documented pre-vault-init end state takes hours. Nothing here asserts unit
health, relation settling, or any service verdict.