Using os_token

Adrian Turjak adriant at
Fri Aug 21 11:30:24 UTC 2020

hah, that's my issue.

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...

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.

On 21/08/20 8:29 pm, Eric K. Miller wrote:
> I happened to run across an unrelated github issue:
> es/271
> which gave me a clue to what I was missing.  I needed to include some
> additional variables (see steps 7 through 9 below).
> Revised steps - which works fine with the OpenStack Client:
> 0) set appropriate OS_* variables for password authentication
> 1) create a token using "openstack token issue"
> 2) unset all OS_* environment variables
> 3) set OS_TOKEN to the token's value provided in #1
> 4) set OS_AUTH_TYPE to "v3token"
> 5) set OS_AUTH_URL to the respective KeyStone endpoint
> 7) set OS_PROJECT_DOMAIN_ID as appropriate
> 8) set OS_PROJECT_NAME as appropriate
> 9) set OS_REGION_NAME as appropriate
> 10) use the CLI as normal
> This shaves anywhere from 0.2 to 0.6 seconds off of a test command I'm
> running when compared to password authentication (which normally takes
> about 2.5 seconds to run), where a new token is issued each time.
> openstack token revoke works as expected too.
> Eric

More information about the openstack-discuss mailing list