[openstack-dev] Splitting notifications from rpc (and questions + work around this)

Joshua Harlow harlowja at fastmail.com
Thu Nov 3 00:11:22 UTC 2016


Hi folks,

There was a bunch of chatter at the summit about how there are really 
two different types of (oslo) messaging usage that exist in openstack 
and how they need not be backed by the same solution type (rabbitmq, 
qpid, kafka...).

For those that were not at the oslo sessions:

https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Oslo

The general gist was though that we need to make sure people really do 
know that there are two very different types of messaging usage in 
openstack and to ensure that operators (and developers) are picking the 
right backing technology for each type.

So some questions naturally arise out of this.

* Where are the best practices with regard to selection of the best 
backend type for rpc (and one for notifications); is this something 
oslo.messaging should work through (or can the docs team and operator 
group also help in making this)?

* What are the tradeoffs in using the same (or different) technology for 
rpc and notifications?

* Is it even possible for all oslo.messaging consuming projects to be 
able to choose 2 different backends, are consuming projects consuming 
the library correctly so that they can use 2 different backends?

* Is devstack able to run with say kafka for notifications and rabbitmq 
for rpc (if not, is there any work item the oslo group can help with to 
make this possible) so that we can ensure and test that all projects can 
work correctly with appropriate (and possibly different) backends?

* Any other messaging, arch-wg work that we (oslo or others) can help 
out with to make sure that projects (and operators) are using the right 
technology for the right use (and not just defaulting to RPC over 
rabbitmq because it exists, when in reality something else might be a 
better choice)?

* More(?)

Just wanted to get this conversation started, because afaik it's one 
that has not been widely circulated (and operators have been setting up 
rabbitmq in various HA and clustered and ... modes, when in reality 
thinking through what and how it is used may be more appropriate); this 
also applies to developers since some technical solutions in openstack 
seem to be created due to (in-part) rabbitmq shortcomings (cells v1 
afaik was *in* part created due to scaling issues).

-Josh



More information about the OpenStack-dev mailing list