Open Stack

On 19/10/15 22:04, Tom Fifield wrote:
> 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?
> 
> Hi,
> 
> 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.
> 
> 

Fog is an interesting and I think very exciting and ambitious project.

Meanwhile I'm not sure it could be a candidate to go along Net/HTTP or
Faraday because it's cloud generic, so quite high level, bringing many
things we don't need at all, unless we could use only the fog/openstack
part.


> 
> Regards,
> 
> 
> Tom
> 
> 
> 
> 
> __________________________________________________________________________
> 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