Open Stack

Clint Byrum wrote:
> Excerpts from Flavio Percoco's message of 2014-09-11 04:14:30 -0700:
>> 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.
> 
> Awesome! Just please don't expect people to get excited about it for
> the lighter weight queueing workloads that you've claimed as use cases.
> 
> I totally see Horizon using it to keep events for users. I see Heat
> using it for stack events as well. I would bet that Trove would benefit
> from being able to communicate messages to users.
> 
> But I think in between Zaqar and the backends will likely be a lighter
> weight queue-only service that the users can just subscribe to when they
> don't want an inbox. And I think that lighter weight queue service is
> far more important for OpenStack than the full blown random access
> inbox.
> 
> I think the reason such a thing has not appeared is because we were all
> sort of running into "but Zaqar is already incubated". Now that we've
> fleshed out the difference, I think those of us that need a lightweight
> multi-tenant queue service should add it to OpenStack.  Separately. I hope
> that doesn't offend you and the rest of the excellent Zaqar developers. It
> is just a different thing.
> 
>> 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.
> 
> No, definitely not broken. It just isn't actually necessary for many of
> the stated use cases.

Clint,

If I read you correctly, you're basically saying the Zaqar is overkill
for a lot of people who only want a multi-tenant queue service. It's
doing A+B. Why does that prevent people who only need A from using it ?

Is it that it's actually not doing A well, from a user perspective ?
Like the performance sucks, or it's missing a key primitive ?

Is it that it's unnecessarily complex to deploy, from a deployer
perspective, and that something only doing A would be simpler, while
covering most of the use cases?

Is it something else ?

I want to make sure I understand your objection. In the "user
perspective" it might make sense to pursue both options as separate
projects. In the "deployer perspective" case, having a project doing A+B
and a project doing A doesn't solve anything. So this affects the
decision we have to take next Tuesday...

Cheers,

-- 
Thierry Carrez (ttx)