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

Davanum Srinivas davanum at gmail.com
Thu Nov 3 00:51:01 UTC 2016


Kirill Bespalov put together this doc of which components will work
with separate rpc and notification configurations:

>From my team, Oleksii Zamiatin is trying to scale up ZMQ beyond 200+
nodes for RPC.

Ilya Tyaptin's review is stuck because Monasca folks have trouble
using the newer python-kafka version:

As you can tell, we are trying to offer RabbitMQ or ZMQ for RPC and
RabbitMQ or Kafka for Notifications.

Hope this helps.


On Wed, Nov 2, 2016 at 8:11 PM, Joshua Harlow <harlowja at fastmail.com> wrote:
> 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
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Davanum Srinivas :: https://twitter.com/dims

More information about the OpenStack-dev mailing list