On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M <kevin....@pnnl.gov> wrote:
> As an Op, a few things that come to mind in that category are: > * RDO packaging (stated earlier). If its not easy to install, its not > going to be deployed as much. I haven't installed it yet, because I haven't > had time to do much other then yum install it... > * Horizon UI > * Heat Resources. (Some basic stuff like create/delete queue to go along > with the stack. also link #1 below) > > Here you go: https://github.com/openstack/heat/tree/master/contrib/heat_zaqar > Horizon has a discovery aspect to it. If users don't know a service is > available, its hard for them to use it. Even with the most simple UI of > Create/Delete/List queues, discovery is handled. The user knows it exists, > and can look for documentation on how to make it work, can ask an admin how > to use it, or start poking at the cli for advanced features. > > Thanks, > Kevin > > 1. https://blueprints.launchpad.net/heat/+spec/software-config-zaqar > ------------------------------ > *From:* Vipul Sabhaya [vip...@gmail.com] > *Sent:* Monday, April 20, 2015 1:39 PM > *To:* OpenStack Development Mailing List (not for usage questions) > > *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?) > > > > On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > >> 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. >> >> > Agreed, it’s not an either/or, there is room for both. While Cue could > provision Zaqar, it doesn’t make sense, since it is already multi-tenant. > As has been said, Cue’s goal is to bring non-multi-tenant message brokers > to the cloud. > > On the question of adoption, what confuses me is why the measurement of > success of a project is whether other OpenStack services are integrating or > not. Zaqar exposes an API that seems best fit for application workloads > running on an OpenStack cloud. The question should be raised to operators > as to what’s preventing them from running Zaqar in their public cloud, > distro, or whatever. > > Looking at other services that we consider to be successful, such as > Trove, we did not attempt to integrate with other OpenStack projects. > Rather, we solved the concerns that operators had. > > > >> Thanks, >> Kevin >> ________________________________________ >> From: Ryan Brown [rybr...@redhat.com] >> Sent: Monday, April 20, 2015 11:38 AM >> To: openstack-dev@lists.openstack.org >> 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: >> 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 > >
__________________________________________________________________________ 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
