Open Stack

On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M <Kevin.Fox at 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 [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> 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]
>> Sent: Monday, April 20, 2015 11:38 AM
>> To: 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://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
>>
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150421/ffa6b127/attachment.html>