Open Stack

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.