Keystone date parse should be able to cope with milliseconds

Bug #904504 reported by justinsb
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Invalid
Undecided
Unassigned

Bug Description

If the date values returned from keystone include milliseconds, it currently fails to parse.

e.g. 2011-12-14T23:42:07.890+0000 gives

2011-12-13 23:39:30,863 ERROR nova.api.openstack.v2 [-] Caught error: invalid literal for int() with base 10: '890+00'
(nova.api.openstack.v2): TRACE: Traceback (most recent call last):
(nova.api.openstack.v2): TRACE: File "/usr/lib/python2.6/site-packages/nova-2012.1-py2.6.egg/nova/api/openstack/v2/__init__.py", line 61, in __call__
(nova.api.openstack.v2): TRACE: return req.get_response(self.application)
(nova.api.openstack.v2): TRACE: File "build/bdist.solaris-2.11-i86pc/egg/webob/request.py", line 1053, in get_response
(nova.api.openstack.v2): TRACE: application, catch_exc_info=False)
(nova.api.openstack.v2): TRACE: File "build/bdist.solaris-2.11-i86pc/egg/webob/request.py", line 1022, in call_application
(nova.api.openstack.v2): TRACE: app_iter = application(self.environ, start_response)
(nova.api.openstack.v2): TRACE: File "/usr/lib/python2.6/site-packages/keystone-2012.1-py2.6.egg/keystone/middleware/auth_token.py", line 270, in __call__
(nova.api.openstack.v2): TRACE: claims = self._verify_claims(env, token)
(nova.api.openstack.v2): TRACE: File "/usr/lib/python2.6/site-packages/keystone-2012.1-py2.6.egg/keystone/middleware/auth_token.py", line 473, in _verify_claims
(nova.api.openstack.v2): TRACE: expires = get_datetime(verified_claims['expires'])
(nova.api.openstack.v2): TRACE: File "/usr/lib/python2.6/site-packages/keystone-2012.1-py2.6.egg/keystone/middleware/auth_token.py", line 130, in get_datetime
(nova.api.openstack.v2): TRACE: ms = int(microseconds.ljust(6, '0')[:6])
(nova.api.openstack.v2): TRACE: ValueError: invalid literal for int() with base 10: '890+00'
(nova.api.openstack.v2): TRACE:

Revision history for this message
justinsb (justin-fathomdb) wrote :

Oops... actually, I think it's actually timezones that it can't cope with.

So, presumably time must be in UTC?

Revision history for this message
Thierry Carrez (ttx) wrote :

Might also be a keystone issue... Is there a specific scenario to get keystone to return such values ?

Changed in nova:
status: New → Incomplete
Revision history for this message
Thierry Carrez (ttx) wrote :

@justin: any chance you could provide us with some reproduction info ?

Revision history for this message
justinsb (justin-fathomdb) wrote :

I think it's just a documentation bug on the keystone spec. Let's not worry about this one.

Changed in nova:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.