<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>