<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 07:13 AM, Vladimir Kuklin
wrote:<br>
</div>
<blockquote
cite="mid:CAHAWLf39v6F8QwjE70CP88VupnZjvmswdvXhgxpaK02HY+NsMA@mail.gmail.com"
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>
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.<br>
<br>
<blockquote
cite="mid:CAHAWLf39v6F8QwjE70CP88VupnZjvmswdvXhgxpaK02HY+NsMA@mail.gmail.com"
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>
openstackclient can output JSON.<br>
<br>
<blockquote
cite="mid:CAHAWLf39v6F8QwjE70CP88VupnZjvmswdvXhgxpaK02HY+NsMA@mail.gmail.com"
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>
This is huge.<br>
<br>
<blockquote
cite="mid:CAHAWLf39v6F8QwjE70CP88VupnZjvmswdvXhgxpaK02HY+NsMA@mail.gmail.com"
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>
This is also huge.<br>
<br>
<blockquote
cite="mid:CAHAWLf39v6F8QwjE70CP88VupnZjvmswdvXhgxpaK02HY+NsMA@mail.gmail.com"
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>
I'm still not convinced.<br>
<br>
<blockquote
cite="mid:CAHAWLf39v6F8QwjE70CP88VupnZjvmswdvXhgxpaK02HY+NsMA@mail.gmail.com"
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
cite="mid:CAHAWLf39v6F8QwjE70CP88VupnZjvmswdvXhgxpaK02HY+NsMA@mail.gmail.com"
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>
I would be in favor of such a plan if
<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>
questions 0.4.1-0.4.7 could be answered in the affirmative.<br>
<br>
<blockquote
cite="mid:CAHAWLf39v6F8QwjE70CP88VupnZjvmswdvXhgxpaK02HY+NsMA@mail.gmail.com"
type="cite">
<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">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">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 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>