Open Stack

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