Open Stack

On 10/13/2015 09:17 AM, Vladimir Kuklin wrote:
> Rich
>
> Thanks for your feedback - let me comment on a couple of things.
>
> First of all, I do not think we have complete support for any action 
> in OpenStack client right now - we still need to rely on 
> neutronclient, glanceclient, etc.

Right.  But those are all being actively maintained, and will have to 
add support for Keystone v3 in order to take advantage of Keystone v3 
features if desired by the clients of those services.

>
> Secondly, regarding Ruby power - this is about any good programming 
> language, not about Ruby - I can simply mention better exception 
> handling as you would not need to parse the output and generate your 
> own exceptions - this makes it easier to support the whole set of 
> providers. As I mentioned earlier, we do not have perfect exception 
> handling for intermittent operational issues.

"As I mentioned earlier" - not sure to what you are referring here. Can 
you please explain how you could do exception handling better with 
native ruby than with openstackclient output?  I mean, you still have to 
"parse" the return value of the http request, to get the code, the error 
message, and any returned values.

>
> Finally, I understand that you do not see metrics. Although, it seems 
> to me absolutely obvious that fork/exec is going to be the problem 
> here, that's OK, I will work on that and come up with quantitative 
> analysis.

It does appear obvious that getting rid of fork/exec will speed up 
puppet runs.  But it is not obvious how much that speed up will be, and 
it is not obvious about the cost of that vs. the current code, and 
cost/performance vs. using openstackclient in "persistent" mode.

>
>
> On Tue, Oct 13, 2015 at 5:18 PM, Rich Megginson <rmeggins at redhat.com 
> <mailto:rmeggins at redhat.com>> wrote:
>
>     On 10/13/2015 07:13 AM, 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
>
>     I think 1), 2), and 3) go together - that is, the reason why 1)
>     and 2) are good is because of 3) - since aviator is native ruby,
>     there is no need to fork/exec. What other "power of Ruby" is there
>     to be taken advantage of?
>
>     As for fork/exec, it remains to be seen that fork/exec is causing
>     a performance problem.  Note that you can also run the
>     openstackclient in "persistent" mode - that is, use it as a
>     persistent pipe, which will read commands from stdin and output to
>     stdout, which should alleviate much if not all of any performance
>     problem caused by multiple fork/exec.  We just haven't
>     investigated this route yet because it needs to be proven that
>     fork/exec causes performance problems.
>
>>     4) You are relying on negotiated and structured output provided
>>     by API (JSON) instead of introducing workarounds for client
>>     output like [1]
>
>     openstackclient can output JSON.
>
>>
>>     * Cons
>>
>>     1) Aviator is not actively supported
>
>     This is huge.
>
>>     2) Aviator does not track all the upstream OpenStack features
>>     while native OpenStack client does support them
>
>     This is also huge.
>
>>     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.
>
>     I'm still not convinced.
>
>>     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 would be in favor of such a plan if
>     https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013
>     questions 0.4.1-0.4.7 could be answered in the affirmative.
>
>>
>>
>>     [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
>>     +7 (926) 702-39-68
>>     Skype kuklinvv
>>     35bk3, Vorontsovskaya Str.
>>     Moscow, Russia,
>>     www.mirantis.com <http://www.mirantis.ru/>
>>     www.mirantis.ru <http://www.mirantis.ru/>
>>     vkuklin at mirantis.com <mailto:vkuklin at mirantis.com>
>>
>>
>>     __________________________________________________________________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru <http://www.mirantis.ru/>
> vkuklin at mirantis.com <mailto:vkuklin at mirantis.com>
>
>
> __________________________________________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151013/eed74ad7/attachment.html>