Open Stack

On 09/10/2014 01:47 AM, Devananda van der Veen wrote:
> On Tue, Sep 9, 2014 at 4:12 PM, Samuel Merritt <sam at swiftstack.com> wrote:
>> On 9/9/14, 12:03 PM, Monty Taylor wrote:
> [snip]
>>> So which is it? Because it sounds like to me it's a thing that actually
>>> does NOT need to diverge in technology in any way, but that I've been
>>> told that it needs to diverge because it's delivering a different set of
>>> features - and I'm pretty sure if it _is_ the thing that needs to
>>> diverge in technology because of its feature set, then it's a thing I
>>> don't think we should be implementing in python in OpenStack because it
>>> already exists and it's called AMQP.
>>
>>
>> Whether Zaqar is more like AMQP or more like email is a really strange
>> metric to use for considering its inclusion.
>>
> 
> I don't find this strange at all -- I had been judging the technical
> merits of Zaqar (ex-Marconi) for the last ~18 months based on the
> understanding that it aimed to provide Queueing-as-a-Service, and
> found its delivery of that to be lacking on technical grounds. The
> implementation did not meet my view of what a queue service should
> provide; it is based on some serious antipatterns (storing a queue in
> an RDBMS is probably the most obvious); and in fact, it isn't even
> queue-like in the access patterns enabled by the REST API (random
> access to a set != a queue). That was the basis for a large part of my
> objections to the project over time, and a source of frustration for
> me as the developers justified many of their positions rather than
> accepted feedback and changed course during the incubation period. The
> reason for this seems clear now...

Let me clarify some points, again:

1. We have never said that our recommended driver is an RBDMS. That
driver was added for reasons that were already explained in this thread.[0]

2. The get-message-by-id feature/bug was not added as 'queue' feature.
When we added it, we were working on messages pagination, that is, a way
to iterate and keep getting messages out of the queue by following the
lead of the last message. When the pagination thing was completed,
adding the get-message-by-id endpoint was easy and cheap, hence we added
it. Our current API version is 1.1 and we *can't* remove that endpoint
until the next major version.

3. You saying that we just justified our positions rather than accepting
the feedback is what frustrates me the most and it just means, with all
due respect, that you haven't followed the project close enough. We've
addressed feedback from *EVERYONE* whenever that was possible. As far as
I can see, your frustration is mostly related to the fact that we
haven't removed the `get-message-by-id` endpoint but as I've mentioned,
we can't do it right now. However, we have talked about it several times
in meetings and a couple of times on the mailing list.[1][2]


[0]
http://lists.openstack.org/pipermail/openstack-dev/2014-March/030367.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2014-May/036131.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-August/044213.html

> 
> As was pointed out in the TC meeting today, Zaqar is (was?) actually
> aiming to provide Messaging-as-a-Service -- not queueing as a service!
> This is another way of saying "it's more like email and less like
> AMQP", which means my but-its-not-a-queue objection to the project's
> graduation is irrelevant, and I need to rethink about all my previous
> assessments of the project.

Zaqar is a messaging service, we changed that almost right before the
Juno summit to help clarify the project goals. [0]

[0] https://wiki.openstack.org/wiki/Zaqar#Overview

> 
> The questions now before us are:
> - should OpenStack include, in the integrated release, a
> messaging-as-a-service component?
> - is Zaqar a technically sound implementation of such a service?

I believe there is. I've been collecting use-cases from integrated
projects and other users. I've put them here[0]

[0] https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases

> 
> As an aside, there are still references to Zaqar as a queue in both
> the wiki [0], in the governance repo [1], and on launchpad [2].

I'm sorry about this, apparently the change was not spread enough
throughout our community, again.


Thanks for your feedback,
Flavio

> 
> 
> [0] "Multi-tenant queues based on Keystone project IDs"
>   https://wiki.openstack.org/wiki/Zaqar#Key_features
> 
> [1] "Queue service" is even the official OpenStack Program name, and
> the mission statement starts with "To produce an OpenStack message
> queueing API and service."
>   http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n315
> 
> [2] "Zaqar is a new OpenStack project to create a multi-tenant cloud
> queuing service...."
>   https://launchpad.net/zaqar
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
@flaper87
Flavio Percoco