Open Stack

On 22/05/15 11:48, Amrith Kumar wrote:
> I’m posting this to the mailing list to summarize my notes from a
> meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
> multi-tenant messaging and how it may be applicable to a number of projects.
>
> I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
> notes and observations after the meeting and how they relate
> specifically to Trove. I don’t claim to speak for Trove, other
> contributors to Trove, other projects who were at the meeting, for
> zaqar, etc., etc.,
>
> After the meeting I think I have a slightly better understanding of what
> Zaqar is but I am still not entirely sure. As best as I can tell, it is
> a lightweight, keystone authenticated, multi-tenant messaging system.

I'm not sure what 'lightweight' means in this context. I'd describe it 
as a keystone-authenticated multi-tenant reliable messaging system a la 
Amazon SQS.

> I
> am still a little troubled that of the many people in the room who were
> knowledgeable of zaqar, there appeared to be some disagreement on how
> best to describe or explain the project.

I don't think there's any disagreement. It just seems to be hard to 
explain to people, because everyone instinctively wants to compare it to 
Rabbit, which is a completely different thing with completely different 
use cases. IMHO part of the problem has been that folks have been 
reluctant to name SQS specifically, and so we end up talking elliptically.

> I learned that users of zaqar can authenticate with keystone and then
> interact with zaqar, and pass messages using it. I learned also that
> zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
> zaquar as I had thought it was.
>
> It became clear that the underlying transport in zaqar is not based on
> an existing AMQP service, rather zaqar is a “from the ground up”
> implementation. This scares me (a lot).

Yes, literally every person who has ever heard of Zaqar complains about 
this and it's getting a little boring. It's irrelevant because Zaqar is 
not a replacement for AMQP, it's a replacement for SQS.

> I gather there is currently no oslo.messaging integration with zaqar;

Right, Zaqar has never been intended as a replacement for Rabbit in Oslo 
messaging.

(Although that could be an interesting idea, it's another discussion 
altogether.)

> for Trove to use zaqar we would have to either (a) abandon
> oslo.messaging and use zaqar, or (b) build in smarts within Trove to
> determine at run time whether we are using zaqar or o.m and implement
> code in Trove to handle the differences between them if any.
>
> It wasn’t clear to me after the meeting what differences there may be
> with Trove; one which was alluded to was the inability to do a
> synchronous (call()) style message and the statement was that this was
> something that “could be built into a driver”.

Where Zaqar really provides the biggest benefit is sending the message 
from the cloud to the user/application (since it can be authenticated by 
Keystone). IMHO the ideal scenario would be that messages from Trove (or 
whatever) to the VM would go over Zaqar, and for messages in the other 
direction would just go straight to the Trove (or whatever) API. The 
problem is that Keystone's authorisation capabilities are not sufficient 
to handle this at the moment. One thing that should be possible in a 
shorter time-frame is a pre-signed URL for a Zaqar queue as a return path.

> It wasn’t clear to me what scale zaqar has been run at and whether
> anyone has in fact deployed and run zaqar at scale, and whether it has
> been battle hardened the way a service like RabbitMQ has. While I hear
> from many that RabbitMQ is a nightmare to scale and manage, I realize
> that it does in fact have a long history of deployments at scale.

I believe that Rackspace deployed it?

> We discussed some of the assumptions being made in the conversation
> relative to the security of the various parties to the communication on
> the existing rabbit message queue and at the conclusion of the meeting I
> believe we left things as below.
>
> (a)Zaqar would be more appealing if it had a simple oslo.messaging
> driver and an easier path to integration by client projects like Trove.
> The rip-and-replace option put a certain damper on the enthusiasm

So the key point here is that Trove regards the VM running the database 
and the Trove agent as within its own security perimeter. (Whether 
that's appropriate is another debate, but it's up to the Trove 
contributors to decide.) In this case, the ability to authenticate to 
the queue using Keystone provides no real value, so this isn't really a 
use case that requires Zaqar.

The same is not true for other projects, like Heat, Murano and Sahara. 
Whenever the agent is outside the security perimeter, we need an 
authenticated, metered, multi-tenant access method.

> (b)Even with an o.m integration, the incremental benefits that zaqar
> brought were diminished by the fact that one would still have to operate
> an AMQP (RabbitMQ) service for the rest of the infrastructure message
> passing needs unless and until all projects decide to abandon RabbitMQ
> in favor of zaqar

This is not at all what was being suggested.

Murano, for example, is running a separate RabbitMQ service to talk to 
its agent on machines that are very much controlled by the user. That's 
the kind of thing that needs to be replaced by a multi-tenant service. 
The session was organised because it was assumed that Trove is in the 
same boat, but it appears that Trove developers don't consider that it is.

> (c)At this time it is likely that there is no net benefit to a project
> like Trove in integrating with zaqar given that the upside is likely
> limited, the downside(s) that we know of are significant, and there is a
> significant unknown risk.

I agree that in that in the case of Trove specifically, there's no 
reason to change unless and until the decision about the location of the 
security boundary is reconsidered.

cheers,
Zane.

> My thanks to the folks from zaqar for having the session, I certainly
> learnt a lot more about the project, and about openstack.
>
> Let me conclude where I began, by saying the preceding is not a ‘minutes
> of the meeting’, merely my notes from the meeting.
>
> Thanks,
>
> -amrith
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>