Open Stack

Excerpts from Alec Hothan (ahothan)'s message of 2015-06-19 17:18:41 -0700:
> 
> Do we have a good understanding of what is expected of zmq wrt rabbitMQ?
> Like in what part of the bell curve or use cases would you see it? Or
> indirectly, where do we see RabbitMQ lacking today that maybe ZMQ could
> handle better?
> I have tried to find any information on very large scale deployment of
> OpenStack and could not get a firm number (in terms of number of compute
> nodes).
> Does the OpenStack foundation keeps track of this information somewhere?
> 

The current scale-out story is cells. I don't have the exact numbers on
nodes per cell, but it's low enough that some larger scale clouds don't
like the economics.

Cells requires a duplication of control-plane infrastructure that makes
scaling out possible, but overly expensive. It's fine if you are stuck
and don't have time to help develop another solution, but if we take a
long look at the way we use RabbitMQ for RPC, it's possible we'd realize
that RabbitMQ is not great for two-way synchronous comms, and in fact,
there's zero reason to ask it to do that well. Using 0mq for that
alone would probably lighten the load enough to expand the scale for
medium-scale users not to have to use cells. Then if we do fanouts and
casts via 0mq doing direct messages, or a scale-out broker like Kafka
or Gearman, then we suddenly have each box doing just a small part of
the control plane scaling, and less spofs.

All of this is not really oslo.messaging work, but architecture work. I
know Robert Collins has been asking for people to take a look at these
types of issues, and I agree with him that they need to be addressed
directly rather than piecemeal. But we have to pay mind to the fact
that what we have now does work for many many users. This is why having
pluggable driver interfaces so experiments can happen at each level
is an important thing to continue supporting. What's not necessarily
important is keeping all the drivers people have tried in tree.