<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><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><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. </div><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 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 href="https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013" target="_blank">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 type="cite"><span class="">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div>[0] <a 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 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 href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br>
<a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br>
<a 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 href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<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>
</pre>
</blockquote>
<br>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a 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 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 href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>