<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/zaqar/+spec/marconi-horizon-integration">https://blueprints.launchpad.net/zaqar/+spec/marconi-horizon-integration</a><br>
<br>
<div class="moz-cite-prefix">On 21/04/15 10:38, Fox, Kevin M wrote:<br>
</div>
<blockquote
cite="mid:1A3C52DFCD06494D8528644858247BF01A1E6AD0@EX10MBOX03.pnnl.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
<div style="direction: ltr;font-family: Tahoma;color:
#000000;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>
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 class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/heat/+spec/software-config-zaqar">https://blueprints.launchpad.net/heat/+spec/software-config-zaqar</a><br>
<div style="font-family: Times New Roman; color: #000000;
font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF604291"><font
color="#000000" face="Tahoma" size="2"><b>From:</b> Vipul
Sabhaya [<a class="moz-txt-link-abbreviated" href="mailto:vipuls@gmail.com">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)<br>
<b>Subject:</b> Re: [openstack-dev] [Zaqar] Call for
adoption (or exclusion?)<br>
</font><br>
</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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:rybrown@redhat.com" target="_blank">rybrown@redhat.com</a>]<br>
Sent: Monday, April 20, 2015 11:38 AM<br>
To: <a moz-do-not-send="true"
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 class="">
<div class="h5"><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 moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: <a class="moz-txt-link-abbreviated" href="mailto:flwang@catalyst.net.nz">flwang@catalyst.net.nz</a>
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-------------------------------------------------------------------------- </pre>
</body>
</html>