On 09/10/2014 01:51 PM, Thierry Carrez wrote:
I think we do need, as Samuel puts it, "some sort of durable
message-broker/queue-server thing". It's a basic application building
block. Some claim it's THE basic application building block, more useful
than database provisioning. It's definitely a layer above pure IaaS, so
if we end up splitting OpenStack into layers this clearly won't be in
the inner one. But I think "IaaS+" basic application building blocks
belong in OpenStack one way or another. That's the reason I supported
Designate ("everyone needs DNS") and Trove ("everyone needs DBs").

With that said, I think yesterday there was a concern that Zaqar might
not fill the "some sort of durable message-broker/queue-server thing"
role well. The argument goes something like: if it was a queue-server
then it should actually be built on top of Rabbit; if it was a
message-broker it should be built on top of postfix/dovecot; the current
architecture is only justified because it's something in between, so
it's broken.

What is the distinction between a message broker and a queue server? To me those terms both imply something broadly similar (message broker perhaps being a little bit more generic). I could see Zaqar perhaps as somewhere between messaging and data-storage.

There are of course quite a lot of "durable message-broker/queue-server things" around already. I understood Zaqar to have been created to address perceived limitations in existing solutions (e.g. requiring less 'babysitting', being 'designed for the cloud' etc). All solutions certainly have their limitations. Zaqar has limitations with respect to existing solutions also.

So while I agree that there is great value in a basic building block for 'messaging as a service' I think the ideal solution would allow different variations, tailored to different patterns of use with a common API for provisioning, managing and monitoring coupled with support for standard protocols.

OpenStack-dev mailing list

Reply via email to