Have a single message bus that carries OpenStack notification traffic independently from the message bus that carries the intra component RPC traffic.
This will allow to

• separate notification traffic that might be consumed externally from the RPC traffic that is always consumed internally
• scale the RPC and notification message busses independently
• provide a single message bus from where notifications can be consumed even if the RPC traffic uses multiple different busses in a multi cell deployment.

Currently identified affected components:

• nova-operator
• cinder-operator
• glance-operator
• neutron-operator

might be also affected:

• keystone-operator
• barbican-operator
• telemetry-operator

An initial proposal of the common service CRD pattern and OpenStackControlPlane CRD change is can be seen in https://github.com/openstack-k8s-operators/nova-operator/pull/948#issuecomment-2777882528

Related Slack discussion: https://redhat-internal.slack.com/archives/C01ED6VJ1SR/p1743782214311109
Summary of the Slack discussion:

• for FR3 we will go with mostly what we already have:
  • cinder and neutron can be configured to emit notification on the RPC message bus via customServiceConfig and Spec.RabbitMqClusterName CRD fields.
  • glance can be configured manually via customServiceConfigSecret to pass a tranport_url to emit notifications on
  • nova will go ahead and implement separate CRD fields in FR3 to support the single but independent notification bus pattern, so that in a multicell deployment the notifications will be consumable from a single bus instead of multiple busses. This is tracked in OSPRH-230

So if ceilometer in FR3 want to consume notifications then those notifications probably need to be emitted to top level RPC bus (namesd RabbitMQCluster/rabbitmq)

• for later FRs we suggest to apply the pattern from OSPRH-230 to cinder-, glance-, neutron-, etc operators and document that we recommend to use a single but separate message bus for all notification traffic.