Open Stack

Rich

Thanks for your feedback - let me comment on a couple of things.

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.

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.

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.


On Tue, Oct 13, 2015 at 5:18 PM, Rich Megginson <rmeggins at redhat.com> wrote:

> On 10/13/2015 07:13 AM, Vladimir Kuklin wrote:
>
> Puppetmaster and Fuelers,
>
> Last week I mentioned that I would like to bring the theme of using native
> ruby OpenStack client and use it within the providers.
>
> 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.
>
> What I saw actually was like that:
>
> * Pros
>
> 1) It is a native ruby client
> 2) We can import it in puppet and use all the power of Ruby
> 3) We will not need to have a lot of forks/execs for puppet
>
>
> 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?
>
> 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.
>
> 4) You are relying on negotiated and structured output provided by API
> (JSON) instead of introducing workarounds for client output like [1]
>
>
> openstackclient can output JSON.
>
>
> * Cons
>
> 1) Aviator is not actively supported
>
>
> This is huge.
>
> 2) Aviator does not track all the upstream OpenStack features while native
> OpenStack client does support them
>
>
> This is also huge.
>
> 3) Ruby community is not really interested in OpenStack (this one is
> arguable, I think)
>
> * Proposed solution
>
> 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.
>
>
> I'm still not convinced.
>
> 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?
>
>
>
>
>
> 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:
>
> 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)
> 2) we gradually improve Aviator code base up to the level that it
> eliminates issues that are mentioned in  'Cons' section
> 3) we introduce additional set of providers and allow users and operators
> to pick whichever they want
> 4) we leave OpenStackClient default one
>
> Would you support it and allow such code to be merged into upstream
> puppet-openstack modules?
>
>
> I would be in favor of such a plan if
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013
> questions 0.4.1-0.4.7 could be answered in the affirmative.
>
>
>
> [0]
> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
> [1]
> https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru
> vkuklin at mirantis.com
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151013/70f37245/attachment.html>