Open Stack

On 12/05/15 09:44, Stan Lagun wrote:
> +1 for making Murano Engine <-> Murano Agent communication plugable so
> that one can switch to Zaqar or anything else.

Cool, thanks.

> However watching RabbitMQ
> development for years I know hard can it be to build efficient and
> reliable system and I'm just not sure Zaqar can compete with such
> battle-proven thing like RabbitMQ yet.

Yep, it's certainly a hard problem. Zaqar has some different constraints 
though - Rabbit is optimised for low-latency and throughput. For Zaqar 
it's more about reliability and scalability.

I don't think the scalability problem is going to be completely solved 
overnight, but I think the important thing at this stage is that the API 
be stable and not present any barriers to improving scalability on the 
back end - and I think the v2 API will do that. For the kinds of 
workloads that something like Murano could throw at it, I think it's 
more than capable already.

> The only advantage I see is multi-tenancy.

The big advantage is in having a single interface across OpenStack for 
this. But yes, multi-tenancy is the main prerequisite for that to happen.

> But I do believe it can be relatively easy be implemented
> with RabbitMQ. At lease in Murano. Don't want to go off topic here. The
> main idea is to use
> https://github.com/rabbitmq/rabbitmq-auth-backend-amqp and dynamically
> grant agent permissions only to his dedicated input queue so that it
> cannot access anything else. Not just other tenants queues but also
> queues of other VMs in the same tenant. In case of Murano we will not
> need to maintain additional secrets or databases. Neither it will be
> needed to create RabbitMQ users/vhosts as all of this becomes virtual.
> And agent will not be holding any RabbitMQ passwords at all

There is more to multi-tenancy than just authentication/authorisation. 
It's also things like making sure one tenant's use of resources doesn't 
affect another tenant's (e.g. creating a denial of service by maxing out 
capacity); being able to measure and bill for usage; quotas to prevent 
accidental overuse &c.

So while adding auth to your current solution is definitely a good thing 
and I would encourage you to do so (in addition to making the whole 
thing pluggable :) I don't think that even an authenticated Rabbit can 
become the single point for messaging across OpenStack. There's too much 
stuff missing for it to be a serious contender for public clouds in 
particular.

That's not to say Rabbit couldn't be used as a back-end to Zaqar, 
although it should be noted that the Zaqar team already investigated 
that in depth and found that it didn't meet their needs (at least at the 
time).

cheers,
Zane.

>
>
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
>
> <mailto:slagun at mirantis.com>
>
> On Tue, May 12, 2015 at 10:52 AM, Renat Akhmerov <rakhmerov at mirantis.com
> <mailto:rakhmerov at mirantis.com>> wrote:
>
>     Zane,
>
>     Fully agree with you vision here.
>
>>     On 12 May 2015, at 07:15, Zane Bitter <zbitter at redhat.com
>>     <mailto:zbitter at redhat.com>> wrote:
>>
>>     * Add an action in Mistral for sending a message to a Zaqar queue.
>>     This is easy and there's no reason you couldn't do it right now.
>
>     Any volunteers?
>
>>     * Add a way to trigger a Mistral workflow with a Zaqar message.
>>     This is one piece in the puzzle to build user-configurable
>>     messaging flows between OpenStack services.[3]
>
>     I added an agenda item for the summit in
>     https://etherpad.openstack.org/p/vancouver-2015-design-summit-mistral to
>     discuss this. Everyone is welcome.
>
>>     Imagine if there were one place where we implemented reliable
>>     queuing semantics at cloud scale, and when we added e.g.
>>     long-polling or WebSockets everyone could benefit immediately.[4]
>>     Imagine if there were one place for notifications, at cloud scale,
>>     for operators to secure. (How many webhook implementations are
>>     there in OpenStack right now? How many of them are actually secure
>>     against malicious users?) One format for messages between services
>>     so that users can connect up their own custom pipelines. We're not
>>     that far away! All of this is within reach if we work together.
>
>     Cool picture of a wonderful future :)
>
>>     Thanks for reading. Please grab me at summit if you want to know
>>     more; I am always happy to bend the ear of anyone who will listen
>>     at length on this topic. As usual, I'll be the tall dude with the
>>     weird accent ;)
>
>     With the great pleasure.
>
>     (P.S. your accent is cool!)
>
>     Renat Akhmerov
>     @ Mirantis Inc.
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>