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.