Thanks Kevin, all good suggestions. Re Horizon UI, yes, we even have a blueprint to track that, but seems the owner didn't complete it. FWIW, I would suggest to put it on the todo list of L.
[1] https://blueprints.launchpad.net/zaqar/+spec/marconi-horizon-integration On 21/04/15 10:38, Fox, Kevin M 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) > > 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 > <mailto: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 <mailto:rybr...@redhat.com>] > Sent: Monday, April 20, 2015 11:38 AM > To: openstack-dev@lists.openstack.org > <mailto: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://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://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 -- Cheers & Best regards, Fei Long Wang (王飞龙) -------------------------------------------------------------------------- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------
__________________________________________________________________________ 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