Open Stack

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.walleck at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150504/654a6ea1/attachment.html>