[openstack-dev] [tripleo][oslo] messaging services update
ansmith at redhat.com
Mon Mar 26 18:58:15 UTC 2018
I wanted to provide an update on the work that has been ongoing to
enhance the deployment of messaging system backends for RPC and
The basis of the change is to introduce oslo messaging RPC and
Notify services in place of the rabbitmq server settings. This will
enable tripleo to continue to deploy a single messaging backend (e.g.
clustered rabbitmq server) but will also provide the ability to
configure separate messaging backends for each oslo messaging
service. The ability to separate the messaging services has been
supported since the newton release and can result in increased
performance, scalability and reliability of an OpenStack deployment.
In addition, it facilitates the use of alternative messaging
backend systems supported by oslo messaging.
Summary of the changes:
tripleo-common changes to introduce separate RPC and Notify users
and passwords for distinct messaging transports
This first puppet-tripleo patch supports both current master and
tripleo-heat-templates update below. Patch only works with a single
messaging backend and is needed to transition through CI properly.
tripleo-heat-templates update to introduce oslo messaging services
in place of rabbitmq server settings. The patch supports separate
RPC and Notify communications via the full set of parameters needed
to define independent transports.
This second puppet-tripleo patch supports separate RPC and Notify
oslo messaging services.
In addition to CI, we have performed numerous local test
deployments across the combination of patch sets and messaging
backends. The deployments include single rabbitmq backends as well as
hybrid deployments that use qdrouterd for RPC and rabbitmq for
We seek as much comments and feedback as possible to ensure that the
changes introduced are transparent to the core services and that there
is no impact on the universal deployment and operation of the rabbitmq
The goal is to land these changes in Rocky-1 so that we can maximize
the amout of testing during the release cycle.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev