Open Stack

On Tue, Apr 19, 2016 at 9:06 AM, Adam Young <ayoung at redhat.com> wrote:

> I wonder how much of that is Token caching.  In a typical CLI use patter,
> a new token is created each time a client is called, with no passing of a
> token between services.  Using a session can greatly decrease the number of
> round trips to Keystone.
>

Not as much as you think (or hope?).  Persistent token caching to disk will
help some, at other expenses though.  Using --timing on OSC will show how
much time the Identity auth round trip cost.

I don't have current numbers, the last time I instrumented OSC there were
significant load times for some modules, so we went a good distance to
lazy-load as much as possible.

What Dan sees WRT a persistent client process, though, is a combination of
those two things: saving the Python loading and the Keystone round trips.

I have (had!) a version of DevStack that put OSC into a subprocess and
called it via pipes to do essentially what Dan suggests.  It saves some
time, at the expense of complexity that may or may not be worth the effort.

One thing missing is any sort of transactional control in the I/O with the
subprocess, ie, an EOT marker.  I planned to add a -0 option (think xargs)
to handle that but it's still down a few slots on my priority list.  Error
handling is another problem, and at this point (for DevStack purposes
anyway) I stopped the investigation, concluding that reliability trumped a
few seconds saved here.

Ultimately, this is one of the two giant nails in the coffin of continuing
to persue CLIs in Python.  The other is co-installability. (See that
current thread on the ML for pain points).  Both are easily solved with
native-code-generating languages.  Go and Rust are at the top of my
personal list here...

dt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160419/8087e3f1/attachment.html>