--
Best
Li Tianqing
At 2015-05-23 13:07:42, "Zane Bitter" <zbit...@redhat.com> wrote:
>On 22/05/15 19:01, Fox, Kevin M wrote:
>> 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.
>
>So what I gathered is that according to the Trove folks you are Doing It
>Wrong(TM), even though you installed it in the default configuration.
>You should have modified the Trove code in undocumented ways to create
>the VMs in a project that Trove itself owns, not the user's project.
Yes
>
>> This is a major problem, and I think our site is going to have to
>> strongly consider uninstalling trove until fixed.
>
>I think if you made that change the configuration it would be a lot less
>dangerous. Arguably even then it would be better to use something
>multi-tenant capable and authenticated (if it's so safe why not use the
>same RabbitMQ as all the other services?), but it would be less of an
>'immediate uninstall' case.
Can you explain how the vm send messages to rabbitmq in management network?
>
>cheers,
>Zane.
>
>> Thanks,
>> Kevin *
>> *
>> ------------------------------------------------------------------------
>> *From:* Zane Bitter
>> *Sent:* Friday, May 22, 2015 12:34:01 PM
>> *To:* openstack-dev@lists.openstack.org
>> *Subject:* Re: [openstack-dev] meeting with the zaqar team at summit; my
>> notes
>>
>> 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-requ...@lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
