Provide option of hybrid messaging backends¶
messaging, rabbitmq, qpid
OpenStack services make use of a message bus system for both remote procedure calls (RPC) between components and to emit notifications. The aim of this spec is to layout a plan for providing an alternative to RabbitMQ for RPC messaging.
RabbitMQ is currently used as the message bus system for all remote procedure calls (RPC) and notifications of OpenStack services deployed by OpenStack-Ansible. While RabbitMQ is well tested and has wide acceptance across OpenStack projects and deployments, it may not be the most efficient option for RPC messaging. A brokerless message queue may provide greater performance of messaging throughput and be less of a bottleneck, particularly in larger scale deployments.
This spec proposes offering Qpid Dispatch Router as an alternative option for RPC messaging within an OpenStack-Ansible deployment.
Deployers will be able be given more options for messaging backends:
RabbitMQ for both RPC and notifications (will remain the default deployment)
Qpid Dispatch Router for RPC (with no dedicated backend for notifications)
Qpid Dispatch Router for RPC and RabbitMQ for notifications (hybrid messaging)
Leave RabbitMQ as the sole option for messaging within OpenStack-Ansible deployments.
Playbooks that deploy OpenStack services will need to be modified to make any required against the deployer’s messaging backend of choice. Roles will need to include additional package dependencies to connect to the Qpid Dispatch Router.
An upgrade scenario will test the migration of a deployment from using RabbitMQ.
The default deployment of Qpid Dispatch Router should provide as close as possible parity with OpenStack-Ansible’s default RabbitMQ deployment including use of TLS/SSL encryption and virtualhost namespacing of messaging data.
Especially in larger scale deployments, there is a potential improvement in the throughput of messages and lowered CPU utilization.
End user impact¶
When chosen to be implemented by a deployer, the changes involved should be transparent to end users.
There would be no immediate impact to deployers as the changes involved would be entirely opt-in initially. For deployers choosing to deploy Qpid Dispatch Router, the service will be installed, likely in a new container, and OpenStack services will be configured to make use of it.
New roles for OpenStack projects should include configuration options to allow for using either RabbitMQ or Qpid Dispatch Router and testing of each.
- Primary assignee:
Create a new role for the installation of Qpid Dispatch Router
Create a playbook to deploy Qpid Dispatch Router
Modify OpenStack service configuration templates within each role to allow a transport URL other than RabbitMQ and default variables to support that
Add required client package dependencies to roles
Create test scenarios in the roles to deploy using Qpid Dispatch Router as the messaging backend for RPC
Create a common playbook for any Qpid Dispatch Router configuration changes required by individual OpenStack projects that the OpenStack project playbooks will consume
Create test scenarios in the integrated gate for greenfield and upgrade deployments
A Qpid Dispatch Router scenario would be created within the roles of OpenStack projects which make use of a message queue and the integrated OpenStack-Ansible repo to ensure installations and deployments, including upgrades, remain functional.
Documentation will need to be added for the configuration options of Qpid services, the configuration options for OpenStack services to make use of Qpid services, and any associated maintenance tasks within the Operations Guide.
AMQP 1.O (Qpid Dispatch Router) Oslo Messaging Driver Reference:
Message Routing- A Next-Generation Alternative to RabbitMQ:
Hybrid Messaging Solutions for Large Scale OpenStack Deployments: