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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
