<div dir="ltr">Puppetmaster and Fuelers,<div><br></div><div>Last week I mentioned that I would like to bring the theme of using native ruby OpenStack client and use it within the providers.<br></div><div><br></div><div>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.</div><div><br></div><div>What I saw actually was like that:</div><div><br></div><div>* Pros</div><div><br></div><div>1) It is a native ruby client</div><div>2) We can import it in puppet and use all the power of Ruby</div><div>3) We will not need to have a lot of forks/execs for puppet </div><div>4) You are relying on negotiated and structured output provided by API (JSON) instead of introducing workarounds for client output like [1]<br></div><div><br></div><div>* Cons</div><div><br></div><div>1) Aviator is not actively supported </div><div>2) Aviator does not track all the upstream OpenStack features while native OpenStack client does support them</div><div>3) Ruby community is not really interested in OpenStack (this one is arguable, I think)</div><div><br></div><div>* Proposed solution</div><div><br></div><div>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.<br></div><div>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?</div><div><br></div><div>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:</div><div><br></div><div>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)</div><div>2) we gradually improve Aviator code base up to the level that it eliminates issues that are mentioned in  'Cons' section</div><div>3) we introduce additional set of providers and allow users and operators to pick whichever they want</div><div>4) we leave OpenStackClient default one</div><div><br></div><div>Would you support it and allow such code to be merged into upstream puppet-openstack modules?</div><div><br></div><div><br></div><div>[0] <a href="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/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J</a><br clear="all"><div>[1] <a href="https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86">https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86</a></div>-- <br><div><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div></div>