<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>Thank you. Ill look for this right away.<br>
<br>
Long term, we would prefer some way for the resources to be associated with the tenant so that it simplifies quotas/billing since there are just instances/volumes we already quota. This would need some kind of service vm flag in nova to prevent via policy non
admins from messing with them.<br>
<br>
In addition, this is still a case where some users had an opertunity to get into a vm they shouldnt, and a multitenant message queue would then have privided extra protection.<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 10:07:42 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 19:01, Fox, Kevin M wrote:<br>
> I believe that trove still needs the multi tenant isolation of a multi<br>
> tenant message queue due to the fact that the vm runs in the tenant, and<br>
> the tenant can then force a reboot, go to the console, root it, and<br>
> inject messages at queues destened for other tenants vm's. And there are<br>
> other routes too.<br>
<br>
So what I gathered is that according to the Trove folks you are Doing It <br>
Wrong(TM), even though you installed it in the default configuration. <br>
You should have modified the Trove code in undocumented ways to create <br>
the VMs in a project that Trove itself owns, not the user's project.<br>
<br>
> This is a major problem, and I think our site is going to have to<br>
> strongly consider uninstalling trove until fixed.<br>
<br>
I think if you made that change the configuration it would be a lot less <br>
dangerous. Arguably even then it would be better to use something <br>
multi-tenant capable and authenticated (if it's so safe why not use the <br>
same RabbitMQ as all the other services?), but it would be less of an <br>
'immediate uninstall' case.<br>
<br>
cheers,<br>
Zane.<br>
<br>
> Thanks,<br>
> Kevin *<br>
> *<br>
> ------------------------------------------------------------------------<br>
> *From:* Zane Bitter<br>
> *Sent:* Friday, May 22, 2015 12:34:01 PM<br>
> *To:* openstack-dev@lists.openstack.org<br>
> *Subject:* Re: [openstack-dev] meeting with the zaqar team at summit; my<br>
> notes<br>
><br>
> 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>
><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>