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 <vkuk...@mirantis.com
<mailto: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 <mailto: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 <mailto: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
<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/>
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://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 <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/>
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://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
__________________________________________________________________________
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
