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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
