I agree that ideally, using a native ruby library would be better, but I also share Matt's concern. We'd need a commitment from more than one person to maintain the library if we went that route.
I think the big advantages I see with the ruby client would be: - Potentially better performance - Faster turn around time for enhancements/bug fixes. My concern here is that we're currently limited by how quickly distros pick up new versions of OpenStack Client. I think if we did end up using a ruby library, we'd also want to make sure it was not only vendored, but also usable independently, to increase the audience. On Tue, Oct 13, 2015 at 8:16 AM, Vladimir Kuklin <vkuk...@mirantis.com> wrote: > Matt > > Thanks for your input. So, I mentioned the following - Fuel guys can > contribute into Ruby client for OpenStack as we are also interested in > making it faster. That's why I asked for support in case we invest > substantial effort (as we do not want to waste our time on things that will > not land into upstream) and asked if the approach that I proposed is OK > with you. > > On Tue, Oct 13, 2015 at 6:07 PM, Matt Fischer <m...@mattfischer.com> > wrote: > >> From a technical point of view, not forking and using a native library >> makes total sense. I think it would likely be faster and certainly cleaner >> than parsing output. Unfortunately I don't think that we have the resources >> to actively maintain the library. I think that's the main blocker for me. >> >> On Tue, Oct 13, 2015 at 7:13 AM, Vladimir Kuklin <vkuk...@mirantis.com> >> 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 >>> 4) You are relying on negotiated and structured output provided by API >>> (JSON) instead of introducing workarounds for client output like [1] >>> >>> * Cons >>> >>> 1) Aviator is not actively supported >>> 2) Aviator does not track all the upstream OpenStack features while >>> native OpenStack client does support them >>> 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. >>> 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? >>> >>> >>> [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: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://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 > >
__________________________________________________________________________ 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
