Open Stack

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
<esubramanian at 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" <davanum at 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 <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
>>
>>__________________________________________________________________________
>>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
> __________________________________________________________________________
> 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