Open Stack

On 10/13/2015 09:22 AM, Clayton O'Neill wrote:
> 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
>

But how much, and is it worth the cost, and also worth the cost vs. 
using openstackclient in "persistent" mode.

>   * 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.
>

IMO this is the biggest problem we have had with using openstackclient - 
being gated by distros, and having to wait months, in some cases, to use 
features supported by the services, which we could have used immediately 
using the API directly.

>
> 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.

. . . and then are we also going to be gated by the distros in the same 
way, waiting for months to get an update to aviator?

>
> On Tue, Oct 13, 2015 at 8:16 AM, Vladimir Kuklin <vkuklin at mirantis.com 
> <mailto: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 <mailto: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 <mailto: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
>             <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 <tel:%2B7%20%28495%29%20640-49-04>
>             +7 (926) 702-39-68 <tel:%2B7%20%28926%29%20702-39-68>
>             Skype kuklinvv
>             35bk3, Vorontsovskaya Str.
>             Moscow, Russia,
>             www.mirantis.com <http://www.mirantis.ru/>
>             www.mirantis.ru <http://www.mirantis.ru/>
>             vkuklin at mirantis.com <mailto:vkuklin at mirantis.com>
>
>             __________________________________________________________________________
>             OpenStack Development Mailing List (not for usage questions)
>             Unsubscribe:
>             OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>             <http://OpenStack-dev-request@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://OpenStack-dev-request@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 <tel:%2B7%20%28495%29%20640-49-04>
>     +7 (926) 702-39-68 <tel:%2B7%20%28926%29%20702-39-68>
>     Skype kuklinvv
>     35bk3, Vorontsovskaya Str.
>     Moscow, Russia,
>     www.mirantis.com <http://www.mirantis.ru/>
>     www.mirantis.ru <http://www.mirantis.ru/>
>     vkuklin at mirantis.com <mailto:vkuklin at mirantis.com>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151013/a13ead2d/attachment.html>