Open Stack

On 09/12/2014 01:56 PM, Flavio Percoco wrote:
> On 09/12/2014 11:36 AM, Thierry Carrez wrote:
>> 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.
> 
> +1
> 
>> 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.
> 
> Let me break the above down into several points so we can discuss them
> separately:
> 
> - Removing that endpoint won't take more than a week. It's an API change
> and it won't affect the existing storage drivers.

For the sake of discussion and to provide more info on this point, I've
done this (there are still some tests to clean-up but that's basically
all that's required):

https://review.openstack.org/#/c/121141/

Flavio

> 
> - Removing that endpoint will certainly make the adoption of other
> messaging technologies easier but there are other things to consider
> besides that specific endpoint (some of them were stated here[0]). In
> any case, removing the endpoint definitely makes it easier.
> 
> - Besides the random access to messages, I'm not clear what other
> concerns there are with regards the current semantics. It'd be nice if
> we could recollect them in this section and discuss them. I took a look
> at the other emails in this thread and it seems to me that the concerns
> that have been raised are more oriented to the project scope and
> use-cases. I also looked at the meeting logs again[1] and the only
> concern related to the semantics I found is about the
> `get-message-by-id` endpoint. Please, correct me if I'm wrong.
> 
> 
> [0] http://blog.flaper87.com/post/marconi-amqp-see-you-later/
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-09-20.01.log.html
> 
> Flavio
> 
>> 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,
>>
> 
> 


-- 
@flaper87
Flavio Percoco