<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>I believe that trove still needs the multi tenant isolation of a multi tenant message queue due to the fact that the vm runs in the tenant, and the tenant can then force a reboot, go to the console, root it, and inject messages at queues destened for other
tenants vm's. And there are other routes too.<br>
<br>
This is a major problem, and I think our site is going to have to strongly consider uninstalling trove until fixed.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Zane Bitter<br>
<b>Sent:</b> Friday, May 22, 2015 12:34:01 PM<br>
<b>To:</b> openstack-dev@lists.openstack.org<br>
<b>Subject:</b> Re: [openstack-dev] meeting with the zaqar team at summit; my notes<br>
</font><br>
<div></div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On 22/05/15 11:48, Amrith Kumar wrote:<br>
> I’m posting this to the mailing list to summarize my notes from a<br>
> meeting at 5pm yesterday at Summit relative to Zaqar and lightweight<br>
> multi-tenant messaging and how it may be applicable to a number of projects.<br>
><br>
> I’ll begin by saying these are not ‘minutes’ of a meeting, merely my<br>
> notes and observations after the meeting and how they relate<br>
> specifically to Trove. I don’t claim to speak for Trove, other<br>
> contributors to Trove, other projects who were at the meeting, for<br>
> zaqar, etc., etc.,<br>
><br>
> After the meeting I think I have a slightly better understanding of what<br>
> Zaqar is but I am still not entirely sure. As best as I can tell, it is<br>
> a lightweight, keystone authenticated, multi-tenant messaging system.<br>
<br>
I'm not sure what 'lightweight' means in this context. I'd describe it <br>
as a keystone-authenticated multi-tenant reliable messaging system a la <br>
Amazon SQS.<br>
<br>
> I<br>
> am still a little troubled that of the many people in the room who were<br>
> knowledgeable of zaqar, there appeared to be some disagreement on how<br>
> best to describe or explain the project.<br>
<br>
I don't think there's any disagreement. It just seems to be hard to <br>
explain to people, because everyone instinctively wants to compare it to <br>
Rabbit, which is a completely different thing with completely different <br>
use cases. IMHO part of the problem has been that folks have been <br>
reluctant to name SQS specifically, and so we end up talking elliptically.<br>
<br>
> I learned that users of zaqar can authenticate with keystone and then<br>
> interact with zaqar, and pass messages using it. I learned also that<br>
> zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t<br>
> zaquar as I had thought it was.<br>
><br>
> It became clear that the underlying transport in zaqar is not based on<br>
> an existing AMQP service, rather zaqar is a “from the ground up”<br>
> implementation. This scares me (a lot).<br>
<br>
Yes, literally every person who has ever heard of Zaqar complains about <br>
this and it's getting a little boring. It's irrelevant because Zaqar is <br>
not a replacement for AMQP, it's a replacement for SQS.<br>
<br>
> I gather there is currently no oslo.messaging integration with zaqar;<br>
<br>
Right, Zaqar has never been intended as a replacement for Rabbit in Oslo <br>
messaging.<br>
<br>
(Although that could be an interesting idea, it's another discussion <br>
altogether.)<br>
<br>
> for Trove to use zaqar we would have to either (a) abandon<br>
> oslo.messaging and use zaqar, or (b) build in smarts within Trove to<br>
> determine at run time whether we are using zaqar or o.m and implement<br>
> code in Trove to handle the differences between them if any.<br>
><br>
> It wasn’t clear to me after the meeting what differences there may be<br>
> with Trove; one which was alluded to was the inability to do a<br>
> synchronous (call()) style message and the statement was that this was<br>
> something that “could be built into a driver”.<br>
<br>
Where Zaqar really provides the biggest benefit is sending the message <br>
from the cloud to the user/application (since it can be authenticated by <br>
Keystone). IMHO the ideal scenario would be that messages from Trove (or <br>
whatever) to the VM would go over Zaqar, and for messages in the other <br>
direction would just go straight to the Trove (or whatever) API. The <br>
problem is that Keystone's authorisation capabilities are not sufficient <br>
to handle this at the moment. One thing that should be possible in a <br>
shorter time-frame is a pre-signed URL for a Zaqar queue as a return path.<br>
<br>
> It wasn’t clear to me what scale zaqar has been run at and whether<br>
> anyone has in fact deployed and run zaqar at scale, and whether it has<br>
> been battle hardened the way a service like RabbitMQ has. While I hear<br>
> from many that RabbitMQ is a nightmare to scale and manage, I realize<br>
> that it does in fact have a long history of deployments at scale.<br>
<br>
I believe that Rackspace deployed it?<br>
<br>
> We discussed some of the assumptions being made in the conversation<br>
> relative to the security of the various parties to the communication on<br>
> the existing rabbit message queue and at the conclusion of the meeting I<br>
> believe we left things as below.<br>
><br>
> (a)Zaqar would be more appealing if it had a simple oslo.messaging<br>
> driver and an easier path to integration by client projects like Trove.<br>
> The rip-and-replace option put a certain damper on the enthusiasm<br>
<br>
So the key point here is that Trove regards the VM running the database <br>
and the Trove agent as within its own security perimeter. (Whether <br>
that's appropriate is another debate, but it's up to the Trove <br>
contributors to decide.) In this case, the ability to authenticate to <br>
the queue using Keystone provides no real value, so this isn't really a <br>
use case that requires Zaqar.<br>
<br>
The same is not true for other projects, like Heat, Murano and Sahara. <br>
Whenever the agent is outside the security perimeter, we need an <br>
authenticated, metered, multi-tenant access method.<br>
<br>
> (b)Even with an o.m integration, the incremental benefits that zaqar<br>
> brought were diminished by the fact that one would still have to operate<br>
> an AMQP (RabbitMQ) service for the rest of the infrastructure message<br>
> passing needs unless and until all projects decide to abandon RabbitMQ<br>
> in favor of zaqar<br>
<br>
This is not at all what was being suggested.<br>
<br>
Murano, for example, is running a separate RabbitMQ service to talk to <br>
its agent on machines that are very much controlled by the user. That's <br>
the kind of thing that needs to be replaced by a multi-tenant service. <br>
The session was organised because it was assumed that Trove is in the <br>
same boat, but it appears that Trove developers don't consider that it is.<br>
<br>
> (c)At this time it is likely that there is no net benefit to a project<br>
> like Trove in integrating with zaqar given that the upside is likely<br>
> limited, the downside(s) that we know of are significant, and there is a<br>
> significant unknown risk.<br>
<br>
I agree that in that in the case of Trove specifically, there's no <br>
reason to change unless and until the decision about the location of the <br>
security boundary is reconsidered.<br>
<br>
cheers,<br>
Zane.<br>
<br>
> My thanks to the folks from zaqar for having the session, I certainly<br>
> learnt a lot more about the project, and about openstack.<br>
><br>
> Let me conclude where I began, by saying the preceding is not a ‘minutes<br>
> of the meeting’, merely my notes from the meeting.<br>
><br>
> Thanks,<br>
><br>
> -amrith<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font>
</body>
</html>