repo-stage-drift-dc0-20260802.txt
=================================
COMPLETE drift picture for `~/repo-stage` on the dc0 RACK (vr1-dc0-rack).
Prep for SWEEP FINDING F1 -- docs/audit/queued-findings-20260802-stage5-edge-fold.txt:18-35.
(NOTE: the runbook-fold register has its OWN F1. This document concerns the SWEEP F1 only.)
READ-ONLY audit. Nothing was copied, moved, edited or created on the rack, on
voffice1, or in the repo. No file content was read from the PKI overlay on any host.
Measured 2026-08-02 by the audit agent.
vcloud repo: /home/jessea123/openstack-caracal-dc-dc
branch dc-dc-stage5-preconditions, HEAD 1cdd607, working tree CLEAN
ASSUMPTION STATED: because the tree is clean at 1cdd607, plain
working-tree `sha256sum` IS the HEAD digest. No per-file
`git show HEAD:<path>` was needed and none was run.
rack: reached as `ssh vr1-dc0-rack` (alias + ProxyJump voffice1 from
~/.ssh/config.d/vr1-sites; no jump was hand-constructed)
headend: reached as `ssh voffice1`; clone measured at
/home/jessea123/openstack-caracal-dc-dc (`ls -d`), HEAD 48d5ef9
WHY THIS AUDIT EXISTS: under D-138 the dc0 RACK is the juju deploy client. It has NO
git clone -- `~/repo-stage` is a hand-staged copy, so nothing detects when it drifts.
=====================================================================
0. HEADLINE
=====================================================================
(A) present in BOTH, DIVERGED ................ 1
(B) repo deploy input, MISSING from rack ..... 0 in the Step-4 deploy closure
2 for LATER steps (6 / HA)
1 CONDITIONAL chain (preflight),
host-pin unruled -- see 4B
(C) rack-only, no repo counterpart ........... 0
(D) present in both, IDENTICAL ............... 13 (12 vs the repo + 1 vs voffice1)
Total regular files under ~/repo-stage: 14 (+4 directories).
`.git` ABSENT -- re-asserted this session, see 1.1. Premise of the whole finding holds.
The ONE diverged file is the one SWEEP F1 already named:
overlays/vr1-dc0-vips.yaml
No SECOND drifted file exists. No orphan exists. The Step-4 deploy closure is
otherwise COMPLETE on the rack, including `./policies/overrides.zip`.
=====================================================================
1. FULL ENUMERATION OF ~/repo-stage ON vr1-dc0-rack
=====================================================================
Command: ssh vr1-dc0-rack "ls -a ~/repo-stage;
find ~/repo-stage -printf '%y %m %s %TY-%Tm-%TdT%TH:%TM:%.2TS %p\n';
find ~/repo-stage -name .git -print;
cd ~/repo-stage && find . -type f | sort | xargs sha256sum"
1.1 -- `.git` ABSENCE RE-ASSERTED
`ls -a ~/repo-stage` -> `. .. bundle.yaml overlays policies scripts`
(no dotfiles of any kind, no `.git`, no `.gitignore`)
`find ~/repo-stage -name .git -print` -> NO OUTPUT.
Consistent with the 2026-08-01 finding (`find / -xdev -maxdepth 5 -name .git
-type d` on the rack returned nothing, docs/audit/stage5-juju-client-blocker-
20260801.txt:253-259). ~/repo-stage remains a provenance-free hand copy.
NOTE: this audit did NOT re-run the host-wide `find / -xdev` -- absence of a
clone ELSEWHERE on the rack is CARRIED from the 08-01 measurement, not re-measured.
1.2 -- TYPE / MODE / SIZE / MTIME (no symlinks; all 14 are regular files)
TIMESTAMP FORM, stated so no reader has to re-derive it: these come from
`find -printf` on the RACK and are HOST-LOCAL and UNANNOTATED. The repo/voffice1
times in sections 2 and 3 are `stat`/`ls` output carrying `+0000`. Do not compare
the two forms to the minute. Every comparison this document draws (see 4A) rests
on a gap of ~26 hours, which survives any plausible host clock skew.
d 775 4096 2026-07-31T12:20:47 ~/repo-stage
f 664 54351 2026-07-31T17:03:32 ~/repo-stage/bundle.yaml
d 775 4096 2026-07-31T02:38:23 ~/repo-stage/overlays
f 664 10479 2026-07-31T20:11:43 ~/repo-stage/overlays/vr1-dc0-machines.yaml
f 600 4682 2026-07-31T02:38:23 ~/repo-stage/overlays/vr1-dc0-octavia-pki.yaml
f 664 4368 2026-07-31T19:48:48 ~/repo-stage/overlays/vr1-dc0-vips.yaml
d 775 4096 2026-07-31T12:20:47 ~/repo-stage/policies
f 664 12192 2026-07-31T12:20:47 ~/repo-stage/policies/domain-manager-policy.yaml
f 664 3419 2026-07-31T12:20:47 ~/repo-stage/policies/overrides.zip
d 775 4096 2026-08-02T06:21:11 ~/repo-stage/scripts
f 664 3618 2026-07-31T02:33:47 ~/repo-stage/scripts/juju-spaces-check.sh
f 664 13388 2026-07-31T02:33:47 ~/repo-stage/scripts/lib-hosts.sh
f 664 15648 2026-07-31T02:33:47 ~/repo-stage/scripts/lib-net.sh
f 775 4707 2026-08-02T06:21:11 ~/repo-stage/scripts/opnsense-api.sh
f 775 6659 2026-08-02T06:21:11 ~/repo-stage/scripts/opnsense-bootstrap-apikey.sh
f 664 2117 2026-08-02T06:21:11 ~/repo-stage/scripts/opnsense-mint-apikey.php
f 664 8951 2026-08-02T06:21:11 ~/repo-stage/scripts/opnsense-set-iface-v4.php
f 775 10218 2026-08-02T06:21:11 ~/repo-stage/scripts/opnsense-set-interface-v4.sh
MODE RE-ASSERTED: overlays/vr1-dc0-octavia-pki.yaml is `600`. SEC-029's
handling requirement still holds on the rack.
1.3 -- INVENTORY COUNT MOVED SINCE THE PRIOR BASELINE, AND THIS IS ITSELF A FINDING
The 2026-08-01 audit recorded ~/repo-stage as a NINE-file copy
(stage5-juju-client-blocker-20260801.txt:256). It is now FOURTEEN.
The delta is exactly the five `opnsense-*` files, all mtime 2026-08-02T06:21:11,
staged during the dc0 edge REBUILD and disclosed as LEFT BEHIND at
docs/audit/dc0-edge-rebuild-20260802.txt:577-579. Their digests there
(`:259-264`) are byte-for-byte the digests measured here, so they were staged
from the repo and have not been touched since.
CONSEQUENCE: the "nine-file copy" phrasing in SEC-029(3) and in the 08-01 audit
is SUPERSEDED as a count. A reader planning the re-stage from the nine-file
figure would omit five files -- not a drift, but an inventory blind spot of
exactly the shape the "a register cannot report what it has no row for" lesson
names. LOGGED, NOT FIXED (hard rule 1); the count lives in prose, not a gate.
1.4 -- RACK DIGESTS (sha256, FULL)
4c8a78527a3100f674642cee24cccb60dbc7015deccd2b93bd14ca4333a4e550 ./bundle.yaml
e3be85e41b4194861bdfd15f717678992d6c32b5b393ba701664bb0e6cbac45e ./overlays/vr1-dc0-machines.yaml
5fc117f1883320422f1854b4a82c9c8025dd912326b25fa6ad95686dad40227f ./overlays/vr1-dc0-octavia-pki.yaml
ed19d989e80da8dacd9fe8ff79beb739494ea8abc1951267ea8bb8fb7bb9bb33 ./overlays/vr1-dc0-vips.yaml
64f99b638a1855b02180e907c9535db8bddc5847a502759a9e0d63c513b63077 ./policies/domain-manager-policy.yaml
02fe1fd7fcf07bfc6088622d4aa8430da53e435d60006d0b81f6b9c2e720a011 ./policies/overrides.zip
adb9dbd38a27e663083f37b64e17ca98d870180f010b8d499a29f3fbfe7d1d5d ./scripts/juju-spaces-check.sh
1a46e949603d52690fd9a42d59e1e46f05522469fca2d4fa149065439b019320 ./scripts/lib-hosts.sh
3e465ae7de3bf92d44326e12240cd411bb7c4e59c1f5b0bb2dd9de4ac23eb81f ./scripts/lib-net.sh
8c2329f87fe72a939cfe48b7fece33685ff8f392949af96b490772453b35c905 ./scripts/opnsense-api.sh
c1bd904489fe6e819463f1c9db483ea054d15586acd05e08fd85285dbbf1b450 ./scripts/opnsense-bootstrap-apikey.sh
2a85225dc6329524b86986c0c1ab3ccb1863b0fe0fd522fd7f6c88e1acca0938 ./scripts/opnsense-mint-apikey.php
ed3c4784e20046aab09b6041030176301bddb5442e2ff4cbb5911390d8bfdc5a ./scripts/opnsense-set-iface-v4.php
5dd78f323df0261b4f9bc32cdb8fbf5e7fcc411e58527d49742716ad8a4bb7ef ./scripts/opnsense-set-interface-v4.sh
=====================================================================
2. REPO-SIDE DIGESTS (vcloud, HEAD 1cdd607, tree clean)
=====================================================================
4c8a78527a3100f674642cee24cccb60dbc7015deccd2b93bd14ca4333a4e550 bundle.yaml
e3be85e41b4194861bdfd15f717678992d6c32b5b393ba701664bb0e6cbac45e overlays/vr1-dc0-machines.yaml
80d861560a6b3c52d96f1ca0857924d249a72b41c7e6f32423ca52b36d2d16a0 overlays/vr1-dc0-vips.yaml
64f99b638a1855b02180e907c9535db8bddc5847a502759a9e0d63c513b63077 policies/domain-manager-policy.yaml
02fe1fd7fcf07bfc6088622d4aa8430da53e435d60006d0b81f6b9c2e720a011 policies/overrides.zip
adb9dbd38a27e663083f37b64e17ca98d870180f010b8d499a29f3fbfe7d1d5d scripts/juju-spaces-check.sh
1a46e949603d52690fd9a42d59e1e46f05522469fca2d4fa149065439b019320 scripts/lib-hosts.sh
3e465ae7de3bf92d44326e12240cd411bb7c4e59c1f5b0bb2dd9de4ac23eb81f scripts/lib-net.sh
8c2329f87fe72a939cfe48b7fece33685ff8f392949af96b490772453b35c905 scripts/opnsense-api.sh
c1bd904489fe6e819463f1c9db483ea054d15586acd05e08fd85285dbbf1b450 scripts/opnsense-bootstrap-apikey.sh
2a85225dc6329524b86986c0c1ab3ccb1863b0fe0fd522fd7f6c88e1acca0938 scripts/opnsense-mint-apikey.php
ed3c4784e20046aab09b6041030176301bddb5442e2ff4cbb5911390d8bfdc5a scripts/opnsense-set-iface-v4.php
5dd78f323df0261b4f9bc32cdb8fbf5e7fcc411e58527d49742716ad8a4bb7ef scripts/opnsense-set-interface-v4.sh
ABSENT-IN-REPO overlays/vr1-dc0-octavia-pki.yaml <- BY CONSTRUCTION, see section 3
Repo mtimes for the diverging/deploy-critical files:
bundle.yaml 54351 2026-07-31 16:43:15 +0000
overlays/vr1-dc0-machines.yaml 10479 2026-07-31 20:04:04 +0000
overlays/vr1-dc0-vips.yaml 4316 2026-08-01 21:29:43 +0000
policies/overrides.zip 3419 2026-07-10 19:24:12 +0000
=====================================================================
3. THE PKI OVERLAY -- ITS OWN ROW, COMPARED TO voffice1, NOT TO THE REPO
=====================================================================
`overlays/vr1-dc0-octavia-pki.yaml` carries the Octavia controller CERT and its
PRIVATE KEY (security-ledger SEC-029). It is GITIGNORED (`.gitignore:46`
`overlays/*octavia-pki.yaml`) and is ABSENT from the vcloud repo tree BY
CONSTRUCTION. A mechanical repo-diff would therefore mis-file it as class (C).
IT IS NOT CLASS (C). Its comparison target is voffice1's clone.
VERIFIED BY sha256 ONLY. Its contents were NOT read, printed, quoted or copied on
any host, and no content-touching command (file/head/grep/cat) was pointed at it.
rack vr1-dc0-rack:~/repo-stage/overlays/vr1-dc0-octavia-pki.yaml
5fc117f1883320422f1854b4a82c9c8025dd912326b25fa6ad95686dad40227f
4682 bytes, mode 0600, mtime 2026-07-31T02:38:23 (the COPY time)
headend voffice1:~/openstack-caracal-dc-dc/overlays/vr1-dc0-octavia-pki.yaml
5fc117f1883320422f1854b4a82c9c8025dd912326b25fa6ad95686dad40227f
4682 bytes, mode 0600 (-rw-------), mtime 2026-07-30 07:01
VERDICT: **IDENTICAL.** Class (D).
The voffice1 path was NOT guessed: `creds-manifests/vm-secret-locations:90`
registers the headend copy as `<repo>/overlays/vr1-dc0-octavia-pki.yaml` and
`:127` registers the rack copy at its measured path; `<repo>` on voffice1 was
resolved by `ls -d ~/openstack-caracal-dc-dc` (exists), not inferred.
HYPOTHESIS TESTED AND NEGATIVE: SEC-029 warns that `octavia-pki.sh reissue`
"must now update BOTH copies, or the rack will deploy a superseded cert", and a
reissue DID run 2026-07-30 (docs/audit/octavia-reissue-executed-20260730.txt).
The rack copy is dated 2026-07-31, i.e. AFTER that reissue, and the digests
agree. The superseded-cert hazard is NOT realized today. It remains OPEN as a
standing hazard for the NEXT reissue -- nothing enforces the dual update.
voffice1's clone is at HEAD 48d5ef9 (one commit behind vcloud's 1cdd607). That
is IRRELEVANT to this comparison: the overlay is gitignored, so it is not
carried by any commit and its currency is independent of the clone's commit lag.
=====================================================================
4. CLASSIFICATION
=====================================================================
--------------------------------------------------------------------
(A) PRESENT IN BOTH, DIGESTS DIVERGED -- 1 file
--------------------------------------------------------------------
overlays/vr1-dc0-vips.yaml
rack ed19d989e80da8dacd9fe8ff79beb739494ea8abc1951267ea8bb8fb7bb9bb33
4368 bytes, mtime 2026-07-31T19:48:48
repo 80d861560a6b3c52d96f1ca0857924d249a72b41c7e6f32423ca52b36d2d16a0
4316 bytes, mtime 2026-08-01 21:29:43
This is exactly the divergence SWEEP F1 measured; the digests reproduce.
CAUSE (from F1): the 2026-08-02 session re-rendered the VIP overlay onto GUA
(26 of 39 v6 legs moved off the retired ULA /64s to f02:20::/f02:21::). The
rack holds the PRE-GUA version. The rack copy is 52 bytes LARGER and OLDER --
both consistent with it being the older render, not a rack-side edit.
CORROBORATION ADDED HERE: voffice1's clone ALSO holds
80d861560a6b3c52d96f1ca0857924d249a72b41c7e6f32423ca52b36d2d16a0, so the rack
is the ONLY host in the chain still carrying the pre-GUA overlay.
NO OTHER FILE DIVERGED. Class (A) is a set of exactly one.
--------------------------------------------------------------------
(B) REPO DEPLOY INPUT, MISSING FROM ~/repo-stage
--------------------------------------------------------------------
The closure was worked out from the artifacts, not assumed. Three tiers.
TIER 1 -- the `juju deploy` closure for vr1-dc0 (runbook Step 4.1/4.2,
dc-dc-phase4-juju-bundle-per-dc.md:566-571):
juju deploy ./bundle.yaml \
--overlay overlays/vr1-dc0-vips.yaml \
--overlay overlays/vr1-dc0-octavia-pki.yaml \
...
plus every LOCAL path referenced from inside the MERGED input -- which is
bundle + overlays, not the bundle alone, because a juju overlay can carry its
own `resources:` block with a local path. The scan was re-run UNCHAINED
(`grep -nE '(^|[^A-Za-z0-9_])\.{0,2}/[A-Za-z0-9._/-]+' <file>` plus
`grep -n -A4 'resources:' <file>`) so a path-shaped value that is not a `.zip`
could not be filtered away, and it was run over ALL THREE scannable merge inputs.
bundle.yaml -- exactly ONE local file reference:
bundle.yaml:227-228 resources: { policyd-override: ./policies/overrides.zip }
(the only other `/`-shaped hits are `:69` prose and `:619` `osd-devices: /dev/vdb`,
a guest block device, not a client-side file.)
overlays/vr1-dc0-vips.yaml and overlays/vr1-dc0-machines.yaml -- ZERO local file
references and NO `resources:` block in either (`grep -n -A4 'resources:'` exits
1 on both). Every `/`-shaped hit is either a COMMENT (`vips:5`, `:27`;
`machines:95`, `:110`, `:128`) or a remote apt source
(`machines:138-180`, sixteen `deb http://10.12.8.4/cloud-archive ...` values --
the dc0 mirror, a NETWORK endpoint, not a client-side file to stage).
These two files were NAMED EXPLICITLY on the grep command line; no `overlays/*`
glob was used, so the PKI overlay could not be swept into a content-reading grep.
overlays/vr1-dc0-octavia-pki.yaml -- DELIBERATELY NOT SCANNED, and it does not
need to be: SEC-029 states it carries the Octavia controller CERT and its
PRIVATE KEY INLINE, so it references no external local file. This is a stated
exclusion with a reason, not a silent hole in the closure.
| Tier-1 input | on rack? | verdict |
|---------------------------------------|----------|--------------------|
| bundle.yaml | YES | identical (D) |
| overlays/vr1-dc0-vips.yaml | YES | DIVERGED (A) |
| overlays/vr1-dc0-octavia-pki.yaml | YES | identical to voffice1 (D) |
| ./policies/overrides.zip | YES | identical (D) |
>>> TIER 1 HAS ZERO CLASS-(B) ROWS. <<<
In particular `./policies/overrides.zip` -- the dependency a prior deploy failed
on -- IS staged, at the repo's digest 02fe1fd7...e720a011, and the relative path
`./policies/overrides.zip` resolves correctly from `~/repo-stage` because
`policies/` was staged as a sibling of `bundle.yaml`. The rack additionally
holds `policies/domain-manager-policy.yaml` (identical to the repo); bundle.yaml
does not reference it, so it is a harmless extra, not a missing input.
TIER 2 -- rack-side scripts the runbook invokes, and their transitive `source` deps.
Computed mechanically (`grep -nE '^\s*(source|\.)\s+'` over every staged script):
scripts/juju-spaces-check.sh:17 -> . "$SCRIPT_DIR/lib-net.sh" STAGED, identical
lib-hosts.sh / lib-net.sh -> source nothing further
So the Step-3.x spaces gate is CLOSED on the rack: no staged script sources an
unstaged library. (lib-hosts.sh is staged and unsourced by juju-spaces-check.sh;
the runbook's own CHECK blocks at :84-85 and :197-198 source both, so its
presence is correct, not surplus.)
CONDITIONAL ROW -- `scripts/preflight.sh` AND ITS ENTIRE CHAIN ARE NOT STAGED.
Runbook Step 3 (`:380`) runs `DC="$DC" bash scripts/preflight.sh`. preflight.sh
is ABSENT from ~/repo-stage, and so is every gate it shells out to:
repo-lint.sh, provider-bundle-check.py, channel_assert.py,
pre-flight-checks.sh, creds-matrix.py, octavia-pki.sh, osd-blank-check.sh
(`scripts/preflight.sh:12-21,118,155-158,220-239`). preflight.sh also `cd`s to a
repo root (`:32-33`), which ~/repo-stage is not.
WHY THIS IS CONDITIONAL AND NOT ASSERTED AS A (B) ROW: the runbook pins Step 3
to voffice1 -- EVERY block in phase4 is labelled `-- voffice1 --` (`:187, :240,
:334, :355, :406, :425, :435, :562, :638, :642`), and `:394-397` states outright
that preflight runs on voffice1 "which is another reason this runs on voffice1"
because two of its gates fail on vcloud by design. D-138 moved the CLOUD-FACING
half into the DC. Whether the repo-side gate moved with it is UNRULED: the
2026-08-01 audit (stage5-juju-client-blocker-20260801.txt:240-249, finding G1)
recorded these voffice1 pins as STALE w.r.t. D-138 and explicitly declined to
edit, owing a DOCFIX sized against every voffice1-pinned juju reference.
I DO NOT RULE IT HERE either. Stated as the fork it is:
- if Step 3 stays on voffice1, preflight is NOT a rack input and this is a
non-row (voffice1 has the full clone);
- if D-138 moves it to the rack, staging preflight.sh alone is INSUFFICIENT --
it needs a repo root, i.e. a real clone, not more hand-staging.
`scripts/dc-egress-check.sh` is deliberately NOT a (B) row: preflight `:354` and
runbook `:487` PIPE it to the rack (`ssh <rack> 'bash -s -- check <dc>' < scripts/
dc-egress-check.sh`), so it is never expected to be resident.
TIER 3 -- inputs for LATER steps, absent from the rack (genuine (B) rows, low urgency):
These are the digests a re-stage must land on the rack:
overlays/dc-dc-ipv6-family-matrix.yaml 3749 bytes
3ef96844f9d2a2ca4df8b971c03943dc47be2d0316900efd39b25ca0678010ca
consumed by Step 6 (`:776-780`) -- DRAFTED 2026-07-10, NOT APPLIED to any
live model (`:767`).
overlays/dc-ha-scaleup.yaml 13146 bytes
5f2e7c993143496a64b3a6f17ddf173c2682acd65e14f4b228461ace1330f7a9
consumed by the later HA step; DELIBERATELY excluded from Step 4 (`:538-541`).
Neither blocks Step 4. Both WILL be needed on the rack under D-138 and neither
is on any register that would notice. Recorded so the re-stage can decide
whether to stage the full overlay set or only the Step-4 set.
--------------------------------------------------------------------
(C) PRESENT ON THE RACK WITH NO REPO COUNTERPART -- 0 files
--------------------------------------------------------------------
NONE. All 14 staged files resolve to a repo path, and 13 of them to a repo file
with a matching digest. The one file with no vcloud counterpart --
overlays/vr1-dc0-octavia-pki.yaml -- is gitignored BY CONSTRUCTION and is
filed in section 3 against voffice1, not here. There is no stale artifact, no
hand-made file, and no orphan under ~/repo-stage.
(Scope note: this class covers ~/repo-stage ONLY. The dc0 edge rebuild left
other non-repo artifacts in the rack's HOME -- ~/d112c-console-dc0-rebuild.py,
its log, ~/.ssh/known_hosts.* backups, ~/d112c-bootstrap.php.b64 -- all
disclosed at dc0-edge-rebuild-20260802.txt:565-585. They are OUTSIDE
~/repo-stage and outside this audit's scope; they were not re-measured.)
--------------------------------------------------------------------
(D) PRESENT IN BOTH, IDENTICAL -- 13 files
--------------------------------------------------------------------
bundle.yaml 4c8a78527a3100f6...4333a4e550
overlays/vr1-dc0-machines.yaml e3be85e41b419486...0e6cbac45e
overlays/vr1-dc0-octavia-pki.yaml 5fc117f188332042...dad40227f (vs voffice1)
policies/domain-manager-policy.yaml 64f99b638a1855b0...c513b63077
policies/overrides.zip 02fe1fd7fcf07bfc...c2e720a011
scripts/juju-spaces-check.sh adb9dbd38a27e663...9f3fbfe7d1d5d
scripts/lib-hosts.sh 1a46e949603d5269...439b019320
scripts/lib-net.sh 3e465ae7de3bf92d...4ac23eb81f
scripts/opnsense-api.sh 8c2329f87fe72a93...453b35c905
scripts/opnsense-bootstrap-apikey.sh c1bd904489fe6e81...85dbbf1b450
scripts/opnsense-mint-apikey.php 2a85225dc6329524...8e1acca0938
scripts/opnsense-set-iface-v4.php ed3c4784e20046aa...1390d8bfdc5a
scripts/opnsense-set-interface-v4.sh 5dd78f323df0261b...7ad8a4bb7ef
(full digests in sections 1.4 / 2 / 3; truncations here are for reading only)
Two of these are worth naming: bundle.yaml 4c8a7852 and vr1-dc0-machines.yaml
e3be85e4 still MATCH, reproducing what SWEEP F1 recorded at the 08-02 close.
=====================================================================
5. ADJACENT FINDING RAISED BY THE ENUMERATION -- NOT FIXED, NOT MINE TO FIX
=====================================================================
`overlays/vr1-dc0-machines.yaml` EXISTS (repo and rack, identical, e3be85e4),
but runbook dc-dc-phase4-juju-bundle-per-dc.md:527-528 states:
"Do not interpolate a machines overlay path for `vr1-dc0` -- there is no
`overlays/vr1-dc0-machines.yaml`"
and the Step-4 dc0 deploy command (`:566-571`) passes only vips + pki. The file
was created 2026-07-29 (its own header, `overlays/vr1-dc0-machines.yaml:3`)
PRECISELY to close a silent-skip hole, and `scripts/preflight.sh:144-145`
unconditionally folds `overlays/${DC}-machines.yaml` into the merged input it
validates when the file is present.
CONSEQUENCE: the P2 gate now validates `bundle.yaml + vips + machines + pki`
while the runbook's Step-4 command deploys `bundle.yaml + vips + pki`. That is
the gate validating a DIFFERENT input than the deploy uses -- the exact defect
preflight's own comment block (`:134-137`) says it was rewritten to eliminate.
The overlay is `applications:`-only and retags nothing (its header), so the
practical blast radius may be nil -- but "may be nil" is not measured, and the
gate/deploy asymmetry is real either way.
NOT DIAGNOSED FURTHER AND NOT FIXED (hard rule 1: findings are logged, not
executed mid-step). It is DOCFIX-shaped and probably shares a bundle with the
D-138 voffice1-pin DOCFIX already owed from the 08-01 audit's G1. Grep for the
next-free DOCFIX-NNN before assigning a number. Do NOT resolve it by deleting
the file or by adding another `[ -f ]` guard -- the file exists to close a guard.
=====================================================================
6. WHAT WAS NOT MEASURED (stated rather than left as a silent gap)
=====================================================================
1. `overlays/vr1-dc0-octavia-pki.yaml` CONTENT. sha256 + size + mode only, on
both hosts, by instruction and by SEC-029. No line of it was read anywhere.
2. The RACK-side digests of the two tier-3 overlays -- they are ABSENT from the
rack, so there is nothing to compare. Their REPO digests ARE recorded in 4B.
3. Whether a git clone exists ELSEWHERE on the rack outside ~/repo-stage. Only
`find ~/repo-stage -name .git` was run this session. Host-wide absence is
CARRIED from the 2026-08-01 `find / -xdev` measurement, not re-measured.
4. Rack artifacts OUTSIDE ~/repo-stage (section (C) scope note). Not enumerated.
5. dc1's `~/repo-stage`. Out of scope; SEC-029 records dc1's PKI overlay as NOT
yet copied, and that claim was NOT re-measured here.
6. voffice1's clone was measured for the PKI overlay, the four Step-4 inputs and
HEAD only. Its full tree was not diffed against vcloud's; its HEAD 48d5ef9 vs
vcloud's 1cdd607 (one commit) was NOT investigated for content impact beyond
confirming the four Step-4 digests agree.
7. NO command in this audit was refused by the permission layer. Nothing was
retried in an altered shape.
=====================================================================
7. DELIVERY NOTES FOR WHOEVER COMMITS THIS FILE
=====================================================================
7.1 -- `bash scripts/repo-lint.sh` FAILS on the pending change set, and this file
is named in the failure:
[FAIL] L10 pending change set modifies state-bearing surface(s)
[docs/audit/: docs/audit/maasdb-pgdump-integrity-dc0-20260802.txt,
docs/audit/repo-stage-drift-dc0-20260802.txt]
without touching docs/CURRENT-STATE.md -- GA-R1 rule 8 (C1): a
status-changing commit updates CURRENT-STATE.md in the SAME commit
FAIL: repo lint (1 fail, 1 warn, 655 files scanned)
(The 1 WARN is the known L1 legacy non-ASCII carve-out in
docs/design-decisions.md, not this file. This file is ASCII + LF.)
NOT ACTIONED HERE: this audit is READ-ONLY by instruction and does not edit repo
files. Satisfying L10 is a CURRENT-STATE.md edit in the committing session --
it is a real obligation, not lint noise, and it must not be worked around.
7.2 -- THE WORKING TREE WAS CLEAN AT 1cdd607 WHEN THIS AUDIT STARTED AND IS NOT
CLEAN NOW. Concurrent work (not this audit's) has since appeared:
M .claude/skills/openstack-cloud-ops/references/platform-traps.md
M .claude/skills/openstack-cloud-ops/references/script-authoring.md
M scripts/preflight.sh
?? docs/audit/maasdb-pgdump-integrity-dc0-20260802.txt
?? docs/changelog-20260802-queued-items.md
This audit created ONLY `docs/audit/repo-stage-drift-dc0-20260802.txt` and
modified NOTHING.
DOES THIS INVALIDATE THE DIGESTS? NO, and it was checked rather than assumed.
None of the files whose sha256 appears in sections 1.4 / 2 / 3 / 4B is in the
modified list, so every recorded repo digest IS the HEAD-1cdd607 digest.
`scripts/preflight.sh` IS modified and IS cited by line number in section 4B
and section 5 -- `git diff -U0` shows the ONLY hunk is `@@ -369 +369,7 @@`, in
the P6 reminders tail. Every line this document cites (`:12-21, :32-33, :118,
:144-145, :155-158, :220-239, :354`) is BELOW 369 and byte-identical in HEAD
and the working tree. The citations stand.
END.
