Cheran, Nova and Neutron already supported this split when we started this exercise. So yes, they are already shipped :)
https://review.openstack.org/#/c/266960/ https://review.openstack.org/#/c/268335/ -- Dims On Thu, Nov 3, 2016 at 1:43 PM, Elancheran Subramanian <esubraman...@godaddy.com> wrote: > Hi Dims, > Thanks for sharing… > > Just wanted to check whether there is any development for Nova and Neutron > going on, which we can leverage? > > Thanks, > Cheran > > > > > On 11/3/16, 12:51 AM, "Davanum Srinivas" <dava...@gmail.com> wrote: > >>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 > __________________________________________________________________________ > 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
