Another parallel is Manilla vs Swift. Both provides something like a share for users to store files.
The former is a multitenant api to provision non multitenant file shares. The latter is a multitenant api to provide file sharing. Cue is a multitenant api to provision non multitenant queues. Zaqar is an api for a multitenant queueing system. They are complimentary services. Thanks, Kevin ________________________________________ From: Ryan Brown [[email protected]] Sent: Monday, April 20, 2015 11:38 AM To: [email protected] Subject: Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?) On 04/20/2015 02:22 PM, Michael Krotscheck wrote: > What's the difference between openstack/zaqar and stackforge/cue? > Looking at the projects, it seems like zaqar is a ground-up > implementation of a queueing system, while cue is a provisioning api for > queuing systems that could include zaqar, but could also include rabbit, > zmq, etc... > > If my understanding of the projects is correct, the latter is far more > versatile, and more in line with similar openstack approaches like > trove. Is there a use case nuance I'm not aware of that warrants > duplicating efforts? Because if not, one of the two should be retired > and development focused on the other. > > Note: I do not have a horse in this race. I just feel it's strange that > we're building a thing that can be provisioned by the other thing. > Well, with Trove you can provision databases, but the MagnetoDB project still provides functionality that trove won't. The Trove : MagnetoDB and Cue : Zaqar comparison fits well. Trove provisions one instance of X (some database) per tenant, where MagnetoDB is one "instance" (collection of hosts to do database things) that serves many tenants. Cue's goal is "I have a not-very-multitenant message bus (rabbit, or whatever)" and makes that multitenant by provisioning one per tenant, while Zaqar has a single install (of as many machines as needed) to support messaging for all cloud tenants. This enables great stuff like cross-tenant messaging, better physical resource utilization in sparse-tenant cases, etc. As someone who wants to adopt Zaqar, I'd really like to see it continue as a project because it provides things other message broker approaches don't. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
