On Tue, Oct 13, 2015 at 5:18 PM, Rich Megginson <rmegg...@redhat.com
<mailto: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
<https://groups.google.com/a/puppetlabs.com/forum/#%21searchin/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 <http://www.mirantis.ru/>
vkuk...@mirantis.com <mailto:vkuk...@mirantis.com>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://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://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 <http://www.mirantis.ru/>
vkuk...@mirantis.com <mailto: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
