On Fri, May 22, 2015 at 8:48 AM, Amrith Kumar <amr...@tesora.com> 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 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. > If we cannot agree on how to explain zaqar, how can projects even think about adopting it? > > > 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 > >
__________________________________________________________________________ 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