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 <rmegg...@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 > vkuk...@mirantis.com > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@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-requ...@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 vkuk...@mirantis.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
