The problem though is that keystoneauth actually does fetch a new token every time even when you supply it with one, but that new token is based on the one you supply, and is a scoped token. It's likely the api for getting a token from an existing one is faster than password auth. I wish there was a way to have the tools actually reuse a given scoped token rather than fetch a new one every time...
Interesting! I was kinda wondering if that was actually what was happening. It still seems like quite a bit of a delay compared to running the OpenStack Client and running commands on its command line repeatedly (as opposed to loading the OpenStack Client each time). I assumed that there was still some work to load Python, etc., but using --debug does show a pull of the service catalog, which is slow. It definitely would be nice to have a way to save/load the "session" that is created by the OpenStack Client to avoid all of the overhead, or, as you said, provide a scoped token. I tested the performance again to be sure I wasn't going crazy, and with OS_TOKEN, it is definitely between 0.2 and 0.6 (most of the time at the higher end of this) seconds faster. Any improvement is good.
OS_TOKEN is also useful/important because of MFA, which otherwise wouldn't work unless you reuse a token. And I'm hoping that when someone has time to work MFA support properly into the cli tool they can hopefully also think about how to make the token reuse better.
You mentioned "MFA support properly". What issue exists? I'm interested since I was about to look into this next. Thanks! Eric