Open Stack

Was not comaparing it in the way you imply below. My point was that
eventhough they are fundamentally different systems, they play
a similar role in the way we use them - the primary purpose being
to facilitate communications between the components of a distributed
system. 
We have found etcd to be simpler and a better fit for what we
are trying to accomplish.

Regards,
Naveen 


On 10/6/16, 10:43 AM, "Jay Pipes" <jaypipes at gmail.com> wrote:

>On 10/06/2016 11:58 AM, Naveen Joy (najoy) wrote:
>> It¹s primarliy because we have seen better stability and scalability
>> with etcd over rabbitmq.
>
>Well, that's kind of comparing apples to oranges. :)
>
>One is a distributed k/v store. The other is a message queue broker.
>
>The way that we (IMHO) over-use the peer-to-peer RPC communication
>paradigm in Nova and Neutron has resulted in a number of design choices
>and awkward code in places like oslo.messaging because of the use of
>broker-based message queue systems as the underlying transport
>mechanism. It's not that RabbitMQ or AMQP isn't scalable or reliable.
>It's that we're using it in ways that don't necessarily fit well.
>
>One might argue that in using etcd and etcd watches in the way you are
>in networking-vpp, that you are essentially using those tools to create
>a simplified pub-sub messaging system and that isn't really what etcd
>was built for and you will end up running into similar fitness issues
>long-term. But, who knows? It might end up being a genius implementation.
>:)
>
>I'm happy to see innovation flourish here and encourage new designs and
>strategies. Let's just make sure we compare apples to apples when making
>statements about performance or reliability.
>
>All the best,
>-jay
>
>__________________________________________________________________________
>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