Flavio Percoco wrote: > On 09/12/2014 12:14 AM, Zane Bitter wrote: >> The final question is the one of arbitrary access to messages in the >> queue (or "queue" if you prefer). Flavio indicated that this effectively >> came for free with their implementation of Pub-Sub. IMHO it is >> unnecessary and limits the choice of potential back ends in the future. >> I would personally be +1 on removing it from the v2 API, and also +1 on >> the v2 API shipping in Kilo so that as few new adopters as possible get >> stuck with the limited choices of back-end. I hope that would resolve >> Clint's concerns that we need a separate, light-weight queue system; I >> personally don't believe we need two projects, even though I agree that >> all of the use cases I personally care about could probably be satisfied >> without Pub-Sub. > > Right, being able to support other backends is one of the reasons we're > looking forward to remove the support for arbitrary access to messages. > As of now, the plan is to remove that endpoint unless a very good use > case comes up that makes supporting other backends not worth it, which I > doubt. The feedback from Zaqar's early adopters is that the endpoint is > indeed not useful.
Thanks Zane, that was indeed useful. I agree with you it would be better to avoid needing 2 separate projects for such close use cases. Let's assume we remove arbitrary access to messages in v2. When you say it would remove limits on the choice of potential backends, does that mean we could have a pure queue backend (like RabbitMQ), at least in theory ? Would a ZaqarV2 address all of Clint and Devananda's concerns about queue semantics ? If yes, then the graduation question becomes, how likely is that work to be completed early enough in Kilo. If it's a no-brainer and takes a week to sort out, I think we could approve Zaqar's Kilo graduation, even if that stretches the "no major API rewrite planned" requirement. But if we think this needs careful discussion so that the v2 API design (and backend support) satisfies the widest set of users, then incubating for another cycle while v2 is implemented seems like the right course of action. We shouldn't graduate if there is any risk we would end up with ZaqarV1 in Kilo, and then have to deprecate it for n cycles just because it was shipped in the official release and therefore inherits its API deprecation rules. Regards, -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev