[openstack-dev] [oslo.messaging][zeromq] Next step

Gordon Sim gsim at redhat.com
Thu Jun 18 21:37:31 UTC 2015


On 06/16/2015 08:51 PM, Alec Hothan (ahothan) wrote:
> I saw Sean Dague mention in another email that RabbitMQ is used by 95% of
> OpenStack users - and therefore does it make sense to invest in ZMQ (legit
> question).

I believe it's used by 95% of users because there is as yet no 
compelling alternative.

The approach taken with the qpid driver was to retain as much of the 
design of the rabbit driver, both in terms of the architecture of the 
driver code itself, and in the underlying broker model it relied on. The 
library used however was based on a different threading model from that 
used for rabbit and deliberately abstracted away from that broker model 
which had a negative effect on the ability to reason about the resulting 
code.

More fundamentally, the qpid driver didn't offer a different design to 
the rabbit driver. It just used a different broker. The broker wasn't 
actually the problem with the rabbit driver though. There was no real 
benefit against which pain encountered during hardening of a less mature 
solution could be offset.

Unfortunately the failure of that effort has left its scars on many in 
the community and continues to colour opinion. I agree that the maturity 
of different solutions needs to be made very clear to user, that there 
must be effective testing under CI, that stale, unmaintained code has to 
be continually removed. There are valuable lessons in that failure which 
we should not ignore. But I don't believe that failure is a reason to 
stifle the emergence of alternative approaches (as described above, the 
qpid driver was not a different approach anyway).

I think store-and-forward is the wrong tool for RPC and end-to-end 
acknowledgement would be better. I think it is better to focus on the 
availability of the communication channel than on consistent replication 
of every single request- and response- message. So I think investing in 
different approaches does make sense.





More information about the OpenStack-dev mailing list