Open Stack

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)