<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 19, 2016 at 9:06 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
    <div><span style="color:rgb(34,34,34)">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.</span><br></div></div></div>
    </div></blockquote></div><div class="gmail_signature"><br></div><div class="gmail_signature">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.</div><div class="gmail_signature"><br></div><div class="gmail_signature">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.</div><div class="gmail_signature"><br></div><div class="gmail_signature">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.</div><div class="gmail_signature"><br></div><div class="gmail_signature">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.</div><div class="gmail_signature"><br></div><div class="gmail_signature">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.</div><div class="gmail_signature"><br></div><div class="gmail_signature">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...</div><div class="gmail_signature"><br></div><div class="gmail_signature">dt</div><div class="gmail_signature"><br></div>
</div></div>