<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">As an Op, a few things that come to mind in that category are:<br>
* 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...<br>
* Horizon UI<br>
* Heat Resources. (Some basic stuff like create/delete queue to go along with the stack. also link #1 below)<br>
<br></div></div></blockquote><div><br></div><div>Here you go:</div><div><a href="https://github.com/openstack/heat/tree/master/contrib/heat_zaqar">https://github.com/openstack/heat/tree/master/contrib/heat_zaqar</a><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">
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.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
1. <a href="https://blueprints.launchpad.net/heat/+spec/software-config-zaqar" target="_blank">https://blueprints.launchpad.net/heat/+spec/software-config-zaqar</a><br>
<div style="font-family:'Times New Roman';color:rgb(0,0,0);font-size:16px">
<hr>
<div style="direction:ltr"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Vipul Sabhaya [<a href="mailto:vipuls@gmail.com" target="_blank">vipuls@gmail.com</a>]<br>
<b>Sent:</b> Monday, April 20, 2015 1:39 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<div><div class="h5"><br>
<b>Subject:</b> Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)<br>
</div></div></font><br>
</div><div><div class="h5">
<div></div>
<div>
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M <span dir="ltr">
<<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Another parallel is Manilla vs Swift. Both provides something like a share for users to store files.<br>
<br>
The former is a multitenant api to provision non multitenant file shares.<br>
The latter is a multitenant api to provide file sharing.<br>
<br>
Cue is a multitenant api to provision non multitenant queues.<br>
Zaqar is an api for a multitenant queueing system.<br>
<br>
They are complimentary services.<br>
<br>
</blockquote>
<div>
<div><br>
</div>
<div>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.</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thanks,<br>
Kevin<br>
________________________________________<br>
From: Ryan Brown [<a href="mailto:rybrown@redhat.com" target="_blank">rybrown@redhat.com</a>]<br>
Sent: Monday, April 20, 2015 11:38 AM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)<br>
<div>
<div><br>
On 04/20/2015 02:22 PM, Michael Krotscheck wrote:<br>
> What's the difference between openstack/zaqar and stackforge/cue?<br>
> Looking at the projects, it seems like zaqar is a ground-up<br>
> implementation of a queueing system, while cue is a provisioning api for<br>
> queuing systems that could include zaqar, but could also include rabbit,<br>
> zmq, etc...<br>
><br>
> If my understanding of the projects is correct, the latter is far more<br>
> versatile, and more in line with similar openstack approaches like<br>
> trove. Is there a use case nuance I'm not aware of that warrants<br>
> duplicating efforts? Because if not, one of the two should be retired<br>
> and development focused on the other.<br>
><br>
> Note: I do not have a horse in this race. I just feel it's strange that<br>
> we're building a thing that can be provisioned by the other thing.<br>
><br>
<br>
Well, with Trove you can provision databases, but the MagnetoDB project<br>
still provides functionality that trove won't.<br>
<br>
<br>
The Trove : MagnetoDB and Cue : Zaqar comparison fits well.<br>
<br>
Trove provisions one instance of X (some database) per tenant, where<br>
MagnetoDB is one "instance" (collection of hosts to do database things)<br>
that serves many tenants.<br>
<br>
Cue's goal is "I have a not-very-multitenant message bus (rabbit, or<br>
whatever)" and makes that multitenant by provisioning one per tenant,<br>
while Zaqar has a single install (of as many machines as needed) to<br>
support messaging for all cloud tenants. This enables great stuff like<br>
cross-tenant messaging, better physical resource utilization in<br>
sparse-tenant cases, etc.<br>
<br>
As someone who wants to adopt Zaqar, I'd really like to see it continue<br>
as a project because it provides things other message broker approaches<br>
don't.<br>
<br>
--<br>
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div></div></div>
</div>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>