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 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 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). I gather there is currently no oslo.messaging integration with zaqar; 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". 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. 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 (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 (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. 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
