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
