Open Stack

On 04/19/2016 11:03 PM, Dean Troyer wrote:
> 
> 
> On Tue, Apr 19, 2016 at 8:17 PM, Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
> 
>     Maybe it is time to revamp Devstack.  Is there some way that,
>     without a major rewrite, it could take better advantage of the CLI?
>     Could we group commands, or migrate sections to python scripts that
>     really all need to be done together?  For example, most of the early
>     prep of the Keystone server moved to keystone-manage bootstrap.  Is
>     there more bootstrap-type behavior we can and should consolidate?
> 
> 
> This is what I was talking about, trying to take advantage of the
> interactive mode that also reads from stdin to do a series of comamnds
> with a single load/auth cycle.  It lacks a LOT of things for a resilient
> use case such as DevStack (error abort or error ignore?, branching,
> everything a DSL would bring).
> 
> And if you'd like to replace stach.sh with stack.py, I'll not stop you,
> just don't call it DevStack.  Now you are building yet another
> deployment tool.  We've also been down that road before. It may well be
> time to retire DevStack, be sure to let us know when those willing to
> sponsor that work show up so they can attempt to learn from some of our
> mistakes and not repeat them the hard way.

I agree that the CLI being slow is an issue. It's an issue that hits all
the developers because it's adding 3 minutes to devstack runs.

We've stated that openstack client is our strategic interface to lead
with. We've also all experienced that it's so terribly slow for a CLI,
that it leaves a bad taste in our mouths.

While there are a lot of things that Devstack could do better
(especially when it comes to loading all keystone data (users / sc
entries), which is the majority of the time spend in osc), it does seem
to paper over a real issue that doesn't seem to be priority #1 for OSC
right now (or any of our CLIs).

So, could we get back to the root question.

What's actually taking the time? Can that be improved? All these
assumptions that openstacksdk or occ make things better make assumptions
they aren't loading as much python code or have dynamic entry points
that contribute to the slowness. There seems to be a lot of assumptions
here, and only Dan brought real data to the table.

So the real question is:

1) is anyone sufficiently motivated to do a data driven analysis (and
propose guidelines to addressing) why our python CLIs are slow?

Dan provided a starting point, but I've seen no one actually volunteer
to complete this work, or decide it's a project priority.

All the statements here of "use Lang Foo", "use Library X instead" are
pretty shoot from the hip with no actual data. Yes, there are
fundamental issues with python module loading.  These are problems that
can be solved if people are willing to do the hard work to profile and
limit the extensibility of the code.

	-Sean

-- 
Sean Dague
http://dague.net