On Tue, Apr 19, 2016 at 7:57 AM, Dean Troyer <dtro...@gmail.com> wrote:
> On Tue, Apr 19, 2016 at 9:06 AM, Adam Young <ayo...@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 > +1 for Rust (though I'd totally support Go as well) as personal choices.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev