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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
