Hi Daryl, the original reason for having a strict check in there was that the auth provider a specialised to the identity provider in use (KeystoneV2AuthProvider, KeystoneV3AuthProvider), and the timestamp format embedded in there is what's provided by keystone's identity v2 and identity v3 token APIs.
But I agree with you that we could relax those checks to be ISO8601, and possibly leave it to keystone tests to validate a specific format of the timestamp. andrea On Mon, May 4, 2015 at 4:40 AM Daryl Walleck <daryl.wall...@rackspace.com> wrote: > Hi folks, > > > > While running Tempest I ran into a bit of interesting behavior. As part of > the Tempest auth client, checks are performed to assure the token in use is > still valid. When parsing the expiry timestamp from the auth response, a > very specific datetime format is expected for Keystone v2 and v3 > respectively: > > > > > https://github.com/openstack/tempest-lib/blob/master/tempest_lib/auth.py#L232 > > > https://github.com/openstack/tempest-lib/blob/master/tempest_lib/auth.py#L313 > > > > Each of these are formats strings are valid under ISO 8601, but a one to > one mapping is being made between Keystone versions and their timestamp > formats. This can be problematic if the timestamps generated by your > identity provider are valid timestamps, but vary in the granularity (second > vs. millisecond vs. microsecond). In my case, I cannot execute any Tempest > tests as this check occurs early in the fixture setup, which halts any test > from running. > > > > The guidance I've observed from the API working group is that any ISO 8601 > timestamp format should be sufficient ( > https://review.openstack.org/#/c/159892/11/guidelines/time.rst). Since > this parsing occurs in client code as opposed to a test, would it be > sufficient to verify that the timestamp is of a valid ISO 8601 format > before parsing it and leave explicit checking to Keystone tests if > necessary? I didn't want to open this as a bug because I realized there > might be some historical context to this decision. I'd be grateful for any > feedback on this point. > > > > Thanks, > > > > Daryl > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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