-
Epic
-
Resolution: Done
-
Critical
-
rhos-18.0.0
-
None
-
as a user I want to get notifications from the deployed nova cluster
-
False
-
False
-
-
Proposed
-
Proposed
-
Done
-
RHOSSTRAT-680 - Use an single but independent message bus for Nova notification traffic
-
Proposed
-
rhos-workloads-compute
-
Proposed
-
0% To Do, 0% In Progress, 100% Done
-
-
- I as a user want to get nova notifications from the 18.0 deployment, from a separate Notifications bus not colocated with either of RPC buses.
- I as a user want to be able to provide a message bus to be used for the notification.
- The deployment engine should support having a single message bus for all cells.
We should discuss the CRD interface as keystone- and barbican-operator uses a generic interface for notification transport_url configuration already. They don't take a RabbitMqCluster name but take a Secret name only and expecting a transport_url field in the Secret. This interface potentially allows other than rabbit based driver to be configured (e.g. kafka)
Stretched Goals
- The deployment engine should support having different message buses per cell
- The deployment engine should support reusing the RPC message bus for notifications
- blocks
-
OSPRH-13064 Provide a workaround for NVMe disk cleanup in 18.0
-
- Closed
-
- is depended on by
-
OSPRH-14896 Retrieve Nova event metrics from VM creation
-
- New
-
- relates to
-
OSPRH-1240 Enable notification support in glance
-
- Closed
-
- split from
-
RHOSSTRAT-680 Use an single but independent message bus for Nova notification traffic
-
- Closed
-
- links to