Token expiration time with memcache->kvs->dogpile is wrong

[Dag Stenstad]

There seems to be a bug somewhere when creating the expiration field for tokens when using the new memcached->kvs->dogpile->memcached storage for tokens.

Aystems are UTC+1 (HW clock, TZ Europe/Oslo), and "[token] expiration = 3600" in configuration, wich is the default.

No requests to any API services (except keystone) worked, all systems reported that token is expired.

Put in some debugging, and it seems the expiration is set to UTC + conf.token.expiration, wich in my case actually is the same time as now().

Setting expiration to a higher value than 3600 makes the token valid.

[Jamie Lennox (jamielennox)]

So keystone tokens use utctime for expiration so it makes sense that the expiry is UTC + conf.token.expiration. That would imply that it is a bug in auth_token middleware that isn't correctly doing utc but on a lookover auth_token i'm pretty certain it's ok (because there was a bug similar to this earlier in the cycle).

My first guess would be that the value that python is reporting for utc is wrong either for keystone or for the other services. Can you do

  python -c "import datetime; print datetime.datetime.utcnow()"

on both keystone and other services just to make sure they are the same, because beyond that i'm somewhat stumped.

[Dag Stenstad (dag-stenstad)]

I did it in the virtualenv belonging to Keystone and in my Havana Nova installation (from packages):

Git Master Keystone $RANDOM server:
(keystone)keystone@host10:/srv/keystone$ python -c "import datetime; print datetime.datetime.utcnow()"
2014-03-25 08:52:20.973085

Havana Nova API + friends:

[baffle@controller1-az1:~] $ python -c "import datetime; print datetime.datetime.utcnow()"
2014-03-25 08:52:46.969481

I did it with some seconds delay, the clocks are synchronized with NTP.

[Dolph Mathews (dolph)]

What's the version of keystoneclient is in the same environment as Nova?

  $ python -c "import keystoneclient; print(keystoneclient.__version__);"

Or:

  $ keystone --version

[Dag Stenstad (dag-stenstad)]

Keystone:

(keystone)keystone@host10:/srv/keystone$ keystone --version
0.6.0

Nova:

[baffle@controller1-az1:~] $ keystone --version
0.3.2

[Dolph Mathews (dolph)]

This might be a known issue with 0.3.2 that was fixed in a later release... you should be able to safely upgrade keystoneclient on your controller.

[Dolph Mathews (dolph)]

Actually appears to be the offending code in 0.3.2, which has since been fixed:

  https://github.com/openstack/python-keystoneclient/blob/0.3.2/keystoneclient/middleware/auth_token.py#L1022-L1025