Open Stack

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 [vipuls at 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.Fox at pnnl.gov
> <mailto:Kevin.Fox at 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 [rybrown at redhat.com <mailto:rybrown at redhat.com>]
>     Sent: Monday, April 20, 2015 11:38 AM
>     To: openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at 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: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-------------------------------------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150421/e468f0e7/attachment-0001.html>