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