[openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

Tom Fifield tom at openstack.org
Mon Oct 19 11:04:48 UTC 2015

On 13/10/15 21:13, 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
> 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?


I'm just throwing this out there since I didn't see it mentioned in 
either this thread or the linked one on the puppet-openstack ML, but ...

... has anyone looked into fog (http://fog.io/ ) ?

In my experience it generally works, and is updated fairly frequently.



More information about the OpenStack-dev mailing list