Open Stack

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 <vkuklin at 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 <matt at 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 <vkuklin at 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
>>> vkuklin at mirantis.com
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>>
>>
>> __________________________________________________________________________
>> 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
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151013/4038bb10/attachment.html>