Josh, Kirill Bespalov put together this doc of which components will work with separate rpc and notification configurations: https://docs.google.com/document/d/1CU0KjL9iV8vut76hg9cFuWQGSJawuNq_cK7vRF_KyAA/edit?usp=sharing
>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: https://review.openstack.org/#/c/332105/ https://review.openstack.org/#/c/316259/ As you can tell, we are trying to offer RabbitMQ or ZMQ for RPC and RabbitMQ or Kafka for Notifications. Hope this helps. Thanks, Dims On Wed, Nov 2, 2016 at 8:11 PM, Joshua Harlow <harlo...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev