Include the URL of your launchpad blueprint:
This spec describes adding two functional capabilities to the messaging services of an overcloud deployment. The first capability is to enable the selection and configuration of separate messaging backends for oslo.messaging RPC and Notification communications. The second capability is to introduce support for a brokerless messaging backend for oslo.messaging RPC communications via the AMQP 1.0 Apache qpid-dispatch-router.
The oslo.messaging library supports the deployment of dual messaging system backends. This enables alternative backends to be deployed for RPC and Notification messaging communications. Users have identified the constraints of using a store and forward (broker based) messaging system for RPC communications and are seeking direct messaging (brokerless) approaches to optimize the RPC messaging pattern. In addition to operational challenges, emerging distributed cloud architectures define requirements around peer-to-peer relationships and geo-locality that can be addressed through intelligent messaging transport routing capabilities such as is provided by the AMQP 1.0 qpid-dispatch-router.
Provide the capability to select and configure alternative transport_url’s for oslo.messaging RPCs and Notifications across overcloud OpenStack services.
Retain the current default behavior to deploy the rabbitMQ server as the messaging backend for both RPC and Notification communications.
Introduce an alternative deployment of the qpid-dispatch-router as the messaging backend for RPC communications.
Utilize the oslo.messaging AMQP 1.0 driver for delivering RPC services via the dispatch-router messaging backend.
The configuration of dual backends for oslo.messaging could be performed post overcloud deployment.
The end result of using the AMQP 1.0 dispatch-router as an alternative messaging backend for oslo.messaging RPC communications should be the same from a security standpoint. The driver/router solution provides SSL and SASL support in parity to the current rabbitMQ server deployment.
The configuration of the dual backends for RPC and Notification messaging communications should be transparent to the operation of the OpenStack services.
Using a dispatch-router mesh topology rather than broker clustering for messaging communications will have a positive impact on performance and scalability by:
The deployment of the dispatch-router, however, will be new to OpenStack operators. Operators will need to learn the architectural differences as compared to a broker cluster deployment. This will include capacity planning, monitoring, troubleshooting and maintenance best practices.
Support for alternative oslo.messaging backends and deployment of qpid-dispatch-router in addition to rabbitMQ should be implemented for tripleo-quickstart.
The oslo.messaging configuration options define a default and additional notification transport_url. If the notification transport_url is not specified, oslo.messaging will use the default transport_url for both RPC and Notification messaging communications.
The transport_url parameter is of the form:
Where the transport scheme specifies the RPC or Notification backend as one of rabbit or amqp, etc. Oslo.messaging is deprecating the host, port and auth configuration options. All drivers will get these options via the transport_url.
Support for dual backends in and AMQP 1.0 driver integration with the dispatch-router depends on oslo.messaging V5.10 or later.
In order to test this in CI, an environment will be needed where dual messaging system backends (e.g. rabbitMQ server and dispatch-router server) are deployed. Any existing hardware configuration should be appropriate for the dual backend deployment.
The deployment documentation will need to be updated to cover the configuration of dual messaging system backends and the use of the dispatch-router. TripleO Heat template examples should also help with deployments using dual backends.