<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/13/2015 09:17 AM, Vladimir Kuklin
wrote:<br>
</div>
<blockquote
cite="mid:CAHAWLf0vLZ3=zFDYAWvep7u+nk12bKb0tyebJ46nj3223MTQ2A@mail.gmail.com"
type="cite">
<div dir="ltr">Rich
<div><br>
</div>
<div>Thanks for your feedback - let me comment on a couple of
things.</div>
<div><br>
</div>
<div>First of all, I do not think we have complete support for
any action in OpenStack client right now - we still need to
rely on neutronclient, glanceclient, etc.</div>
</div>
</blockquote>
<br>
Right. But those are all being actively maintained, and will have
to add support for Keystone v3 in order to take advantage of
Keystone v3 features if desired by the clients of those services.<br>
<br>
<blockquote
cite="mid:CAHAWLf0vLZ3=zFDYAWvep7u+nk12bKb0tyebJ46nj3223MTQ2A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Secondly, regarding Ruby power - this is about any good
programming language, not about Ruby - I can simply mention
better exception handling as you would not need to parse the
output and generate your own exceptions - this makes it easier
to support the whole set of providers. As I mentioned earlier,
we do not have perfect exception handling for intermittent
operational issues.</div>
</div>
</blockquote>
<br>
"As I mentioned earlier" - not sure to what you are referring here.
Can you please explain how you could do exception handling better
with native ruby than with openstackclient output? I mean, you
still have to "parse" the return value of the http request, to get
the code, the error message, and any returned values.<br>
<br>
<blockquote
cite="mid:CAHAWLf0vLZ3=zFDYAWvep7u+nk12bKb0tyebJ46nj3223MTQ2A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Finally, I understand that you do not see metrics.
Although, it seems to me absolutely obvious that fork/exec is
going to be the problem here, that's OK, I will work on that
and come up with quantitative analysis. <br>
</div>
</div>
</blockquote>
<br>
It does appear obvious that getting rid of fork/exec will speed up
puppet runs. But it is not obvious how much that speed up will be,
and it is not obvious about the cost of that vs. the current code,
and cost/performance vs. using openstackclient in "persistent" mode.<br>
<br>
<blockquote
cite="mid:CAHAWLf0vLZ3=zFDYAWvep7u+nk12bKb0tyebJ46nj3223MTQ2A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Oct 13, 2015 at 5:18 PM, Rich
Megginson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 10/13/2015 07:13 AM, Vladimir Kuklin wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Puppetmaster and Fuelers,
<div><br>
</div>
<div>Last week I mentioned that I would like to
bring the theme of using native ruby OpenStack
client and use it within the providers.<br>
</div>
<div><br>
</div>
<div>Emilien told me that I had already been late
and the decision was made that puppet-openstack
decided to not work with Aviator based on [0]. I
went through this thread and did not find any
unresolvable issues with using Aviator in
comparison with potential benefits it could have
brought up.</div>
<div><br>
</div>
<div>What I saw actually was like that:</div>
<div><br>
</div>
<div>* Pros</div>
<div><br>
</div>
<div>1) It is a native ruby client</div>
<div>2) We can import it in puppet and use all the
power of Ruby</div>
<div>3) We will not need to have a lot of
forks/execs for puppet <br>
</div>
</div>
</blockquote>
<br>
</span> I think 1), 2), and 3) go together - that is, the
reason why 1) and 2) are good is because of 3) - since
aviator is native ruby, there is no need to fork/exec.
What other "power of Ruby" is there to be taken advantage
of?<br>
<br>
As for fork/exec, it remains to be seen that fork/exec is
causing a performance problem. Note that you can also run
the openstackclient in "persistent" mode - that is, use it
as a persistent pipe, which will read commands from stdin
and output to stdout, which should alleviate much if not
all of any performance problem caused by multiple
fork/exec. We just haven't investigated this route yet
because it needs to be proven that fork/exec causes
performance problems.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>4) You are relying on negotiated and structured
output provided by API (JSON) instead of
introducing workarounds for client output like [1]<br>
</div>
</div>
</blockquote>
<br>
</span> openstackclient can output JSON.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>* Cons</div>
<div><br>
</div>
<div>1) Aviator is not actively supported <br>
</div>
</div>
</blockquote>
<br>
</span> This is huge.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>2) Aviator does not track all the upstream
OpenStack features while native OpenStack client
does support them</div>
</div>
</blockquote>
<br>
</span> This is also huge.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>3) Ruby community is not really interested in
OpenStack (this one is arguable, I think)</div>
<div><br>
</div>
<div>* Proposed solution</div>
<div><br>
</div>
<div>While I completely understand all the cons
against using Aviator right now, I see that Pros
above are essential enough to change our mind and
invest our own resources into creating really good
OpenStack binding in Ruby.<br>
</div>
</div>
</blockquote>
<br>
</span> I'm still not convinced.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Some are saying that there is not so big
involvement of Ruby into OpenStack. But we are
actually working with Puppet/Ruby and are invloved
into community. So why should not we own this by
ourselves and lead by example here?</div>
</div>
</blockquote>
<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>I understand that many of you do already have a
lot of things on their plate and cannot or would
not want to support things like additional library
when native OpenStack client is working reasonably
well for you. But if I propose the following
scheme to get support of native Ruby client for
OpenStack:</div>
<div><br>
</div>
<div>1) we (community) have these resources
(speaking of the company I am working for, we at
Mirantis have a set of guys who could be very
interested in working on Ruby client for
OpenStack)</div>
<div>2) we gradually improve Aviator code base up to
the level that it eliminates issues that are
mentioned in 'Cons' section</div>
<div>3) we introduce additional set of providers and
allow users and operators to pick whichever they
want</div>
<div>4) we leave OpenStackClient default one</div>
<div><br>
</div>
<div>Would you support it and allow such code to be
merged into upstream puppet-openstack modules?</div>
</div>
</blockquote>
<br>
</span> I would be in favor of such a plan if <a
moz-do-not-send="true"
href="https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013"
target="_blank"><a class="moz-txt-link-freetext" href="https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013">https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013</a></a>
questions 0.4.1-0.4.7 could be answered in the
affirmative.<br>
<br>
<blockquote type="cite"><span class="">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div>[0] <a moz-do-not-send="true"
href="https://groups.google.com/a/puppetlabs.com/forum/#%21searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J"
target="_blank">https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J</a><br
clear="all">
<div>[1] <a moz-do-not-send="true"
href="https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86"
target="_blank">https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86</a></div>
-- <br>
<div>
<div dir="ltr">
<div>
<div dir="ltr">Yours Faithfully,<br>
Vladimir Kuklin,<br>
Fuel Library Tech Lead,<br>
Mirantis, Inc.<br>
+7 (495) 640-49-04<br>
+7 (926) 702-39-68<br>
Skype kuklinvv<br>
35bk3, Vorontsovskaya Str.<br>
Moscow, Russia,<br>
<a moz-do-not-send="true"
href="http://www.mirantis.ru/"
target="_blank">www.mirantis.com</a><br>
<a moz-do-not-send="true"
href="http://www.mirantis.ru/"
target="_blank">www.mirantis.ru</a><br>
<a moz-do-not-send="true"
href="mailto:vkuklin@mirantis.com"
target="_blank">vkuklin@mirantis.com</a></div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</span>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a moz-do-not-send="true" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<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>
</pre>
</blockquote>
<br>
</div>
<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"
rel="noreferrer" 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"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">Yours Faithfully,<br>
Vladimir Kuklin,<br>
Fuel Library Tech Lead,<br>
Mirantis, Inc.<br>
+7 (495) 640-49-04<br>
+7 (926) 702-39-68<br>
Skype kuklinvv<br>
35bk3, Vorontsovskaya Str.<br>
Moscow, Russia,<br>
<a moz-do-not-send="true" href="http://www.mirantis.ru/"
target="_blank">www.mirantis.com</a><br>
<a moz-do-not-send="true" href="http://www.mirantis.ru/"
target="_blank">www.mirantis.ru</a><br>
<a moz-do-not-send="true"
href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></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>
</body>
</html>