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:sla...@mirantis.com> On Tue, May 12, 2015 at 10:52 AM, Renat Akhmerov <rakhme...@mirantis.com <mailto:rakhme...@mirantis.com>> wrote: Zane, Fully agree with you vision here.On 12 May 2015, at 07:15, Zane Bitter <zbit...@redhat.com <mailto:zbit...@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-requ...@lists.openstack.org?subject:unsubscribe <http://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
