Open Stack

On 09/10/2014 03:45 PM, Gordon Sim wrote:
> 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.

I agree with Gordon here. I really don't know how to say this without
creating more confusion. Zaqar is a messaging service. Messages are the
most important entity in Zaqar. This, however, does not forbid anyone to
use Zaqar as a queue. It has the required semantics, it guarantees FIFO
and other queuing specific patterns. This doesn't mean Zaqar is trying
to do something outside its scope, it comes for free.

Is Zaqar being optimized as a *queuing* service? I'd say no. Our goal is
to optimize Zaqar for delivering messages and supporting different
messaging patterns.

Should we remove all the semantics that allow people to use Zaqar as a
queue service? I don't think so either. Again, the semantics are there
because Zaqar is using them to do its job. Whether other folks may/may
not use Zaqar as a queue service is out of our control.

This doesn't mean the project is broken.


> 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.

Agreed, again. Zaqar has a long way ahead but a clear goal. New features
will be proposed by the community once, hopefully, it's adopted by more
and more users. The project will obviously evaluated them all and make
sure that whatever gets implemented fits in the project goals.

> 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.

I agree there's lots of space for other messaging related services. One
of the ideas that has come up quite a few times is having a service that
provisions message brokers (or other messaging technologies). However, I
believe that's a complete different service and it's out of the scope of
what Zaqar wants to do.

That said, I'm really looking forward to see a project like that emerge
in the future.

Thanks a lot for your feedback,
Flavio

-- 
@flaper87
Flavio Percoco