diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 1c3e22c..a33fd7a 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -2063,6 +2063,18 @@ making ovn-central effectively single-space while leaving D-052 isolation intact for every other app. Alternatives: os-internal/admin/public-network config; escalate LP #2044324. Needs an operator ruling (it amends D-052 for one app) and live verification. + **>>> RULED 2026-08-03 (GA-R5, D-052 AMENDMENT): "ovn-central should be in metal-internal." + <<<** ovn-central's `""` default binding moves metal-admin -> metal-internal (its certificates + + ovsdb* endpoints already live there); D-052 isolation unchanged for every other app. Full + text: `docs/design-decisions.md` D-052 amendment 2026-08-03. + **BUNDLE PLANE-PURPOSE SWEEP DONE (operator-requested), all 56 apps, capture + `docs/audit/binding-plane-purpose-sweep-20260803.txt`:** exactly ONE other deviation -- + `openstack-dashboard:cluster` binds metal-admin where D-052 places cluster peers on + metal-internal (sole outlier of 14 cluster-carrying apps; functionally benign but off-intent) + -- PROPOSED, not yet ruled. Four classifier flags verified NON-issues (octavia:ovsdb-cms + dangling/unused; ceph-radosgw public/object-store/cluster are gateway endpoints correctly + placed). NEXT: apply the ovn-central rebind (bundle + live `juju bind`), verify ovn-central + gets its server cert and the OVN cluster forms; decide the dashboard fix. **>>> PRE-VAULT-INIT END STATE REACHED; VAULT PREFLIGHT PASSES `PROCEED` 2026-08-03. <<<** After the stall fix, the model converged: `scripts/phase-02-vault-preflight.sh vr1-dc0` (staged + sha256-verified on the rack, `90910dfb`) reports **PROCEED** -- mysql cluster 3/3 diff --git a/docs/audit/binding-plane-purpose-sweep-20260803.txt b/docs/audit/binding-plane-purpose-sweep-20260803.txt new file mode 100644 index 0000000..eaad98c --- /dev/null +++ b/docs/audit/binding-plane-purpose-sweep-20260803.txt @@ -0,0 +1,58 @@ +binding-plane-purpose-sweep-20260803.txt +======================================== +Operator-requested (2026-08-03): "ovn-central should be in metal-internal. Complete a +bundle sweep for any other bindings that are bound to a plane that does not match the +planes intended purpose." + +METHOD: extracted every binding of all 56 apps in bundle.yaml, classified each endpoint +against D-052's plane purposes (with Ceph/data-plane context rules), flagged deviations, +then VERIFIED each flag against the actual relation topology (a classifier flag is an +observation, not a conclusion). + +D-052 PLANE PURPOSES (docs/design-decisions.md D-052): + provider-public : public API endpoints + floating IPs + metal-admin : operator/MAAS/monitoring + admin API endpoint + "" default binding + metal-internal : ALL service-to-service control (internal API, shared-db, amqp, + certificates/secrets, cache, CLUSTER PEERS, ovsdb*, identity, inter-svc) + data-tenant : tenant geneve overlay (nova-compute:neutron-plugin, ovn-chassis:data, + ovn-chassis-octavia:data, octavia:ovsdb-cms) + storage : Ceph public (rbd client + mon + ceph control) + replication : Ceph OSD cluster replication + +RAW FLAGS: 6. AFTER VERIFICATION: 2 real, 4 non-issues. + +-------------------------------------------------------------------------------------- +REAL DEVIATIONS (2) +-------------------------------------------------------------------------------------- +1. ovn-central (default) metal-admin -> metal-internal [RULED FIX] + The "" default is what the charm's internal/admin/public cert resolution falls back to. + On metal-admin (multi-space) it triggers LP #2044324 and ovn-central never gets a server + cert -> OVN DB cluster never forms. Its certificates+ovsdb* endpoints already live on + metal-internal; moving the default there makes ovn-central single-space for resolution. + Operator ruling 2026-08-03: "ovn-central should be in metal-internal." (D-052 amendment + for one app; isolation intact elsewhere.) + +2. openstack-dashboard cluster metal-admin -> metal-internal [FOUND BY SWEEP] + `cluster` is the dashboard's HA peer relation. D-052 places cluster peers on + metal-internal, and EVERY other app with a cluster endpoint binds it there (barbican, + cinder, glance, keystone, magnum, mysql-innodb-cluster, neutron-api, nova-cloud-controller, + octavia, placement, rabbitmq, vault, memcached). openstack-dashboard is the SOLE outlier + -- an oversight, not intent. Functionally works on metal-admin but violates the D-052 + service-to-service-on-metal-internal intent. Recommend fix to metal-internal. + +-------------------------------------------------------------------------------------- +VERIFIED NON-ISSUES (4) -- classifier false positives, confirmed against relations +-------------------------------------------------------------------------------------- +3. octavia ovsdb-cms data-tenant -- NOT A FIX. The only ovsdb-cms relation is + neutron-api-plugin-ovn:ovsdb-cms - ovn-central:ovsdb-cms; octavia:ovsdb-cms is in NO + relation (octavia reaches OVN via the ovn-chassis-octavia subordinate). Dangling/inert, + and D-052 explicitly lists octavia:ovsdb-cms under data-tenant anyway. +4. ceph-radosgw public provider-public -- CORRECT. radosgw is a GATEWAY; `public` is its + S3/Swift public API endpoint, not the Ceph public network. +5. ceph-radosgw object-store metal-internal -- CORRECT. service-to-service API relation. +6. ceph-radosgw cluster metal-internal -- CORRECT. radosgw peer HA, not Ceph OSD cluster. + (ceph-radosgw:mon -> storage IS correct: it reaches ceph-mon on the storage plane.) + +-------------------------------------------------------------------------------------- +CONCLUSION: fix 2 bindings -- ovn-central (default) and openstack-dashboard:cluster, +both -> metal-internal. Every other binding matches its plane's D-052 purpose. diff --git a/docs/design-decisions.md b/docs/design-decisions.md index 5e0e6ae..d010a07 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -864,6 +864,41 @@ **Related:** D-051 (combined in the SAME redeploy -- RBAC is keystone-only / low blast radius); supersedes the three conflicting D-052 drafts; depends on the MAAS rename/re-IP/new-VLAN gate (R1); the regenerated bundle differs substantially from BOTH repo HEAD (old space names) and the WIP bundle.yaml (which was Option-1 scope: only `internal` on metal-internal). +### AMENDMENT 2026-08-03 -- ovn-central's `""` default binding moves metal-admin -> metal-internal; and a full-bundle plane-purpose sweep + +**Operator ruling, exact utterance: "ovn-central should be in metal-internal."** (Follow-on same message: "Complete a bundle sweep for any other bindings that are bound to a plane that does not match the planes intended purpose.") + +**WHY.** The FIRST real deploy of D-052's multi-space bindings (2026-08-03) exposed +`charm-ovn-central` bug **LP #2044324** (multi-space-specific): ovn-central resolves its +internal/admin/public cert addresses via the `""` DEFAULT binding, and on `metal-admin` in a +multi-space model it finds no address, skips the server-cert request, and never gets a server +cert -- so its TLS OVSDB listeners never start and the OVN NB/SB Raft cluster never forms +(measured: "joining cluster", nothing on 6641/6642). Its `certificates` and `ovsdb*` endpoints +already bind `metal-internal`; moving the `""` default there makes ovn-central effectively +single-space for cert resolution (the shape of every SUCCESSFUL pre-D-052 single-`metal` +deploy) while leaving D-052 isolation intact for every other app. Pre-D-052 ovn-central used +`bindings: *internal-bindings` = `"": metal` (one space) -- so this is not restoring a dropped +binding, it is adapting ONE app to the multi-space model the charm mishandles. + +**SCOPE: this amends the `""` default for `ovn-central` ONLY.** Every other app keeps its +D-052 bindings. The API charms (keystone et al.) are multi-space too and resolve certs +correctly; the defect is specific to the ovn-central charm. + +**THE PLANE-PURPOSE SWEEP (all 56 apps, capture `docs/audit/binding-plane-purpose-sweep-20260803.txt`).** +Every binding was classified against the plane purposes above and verified against the relation +topology. Result: exactly ONE other deviation -- +**`openstack-dashboard:cluster` binds `metal-admin` where D-052 places cluster PEERS on +`metal-internal`**; it is the sole outlier among 14 apps carrying a `cluster` endpoint (all +others `metal-internal`), an oversight not intent. Four classifier flags were verified NON-issues +(octavia:ovsdb-cms is a dangling endpoint in no relation; ceph-radosgw public/object-store/cluster +are gateway API/service/peer endpoints correctly placed). **The dashboard fix is PROPOSED, not +yet ruled** -- presented for the operator's decision; it is a genuine D-052-intent deviation but +functionally benign (dashboard HA peering works on metal-admin), so it is not urgent. + +**Roosevelt delta:** the per-DC bundle template binds ovn-central's `""` default to +metal-internal from the start; a charm that resolves endpoint addresses via the default binding +needs that default on the plane its certs live on, or it hits LP #2044324 on any multi-space DC. + ## D-053 -- Rename network space `fabric-data` -> `data-tenant` (2026-06-25) **Status:** ADOPTED. Naming-only change to the D-052 plane set; no architectural change.