<div dir="ltr">Hi Daryl,<br><br>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.<div><br><div>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. </div></div><div><br></div><div>andrea</div></div><br><div class="gmail_quote">On Mon, May 4, 2015 at 4:40 AM Daryl Walleck <<a href="mailto:daryl.walleck@rackspace.com">daryl.walleck@rackspace.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi folks,</p>
<p> </p>
<p>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:</p>
<p> </p>
<p><a href="https://github.com/openstack/tempest-lib/blob/master/tempest_lib/auth.py#L232" target="_blank">https://github.com/openstack/tempest-lib/blob/master/tempest_lib/auth.py#L232</a></p>
<p><a href="https://github.com/openstack/tempest-lib/blob/master/tempest_lib/auth.py#L313" target="_blank">https://github.com/openstack/tempest-lib/blob/master/tempest_lib/auth.py#L313</a></p>
<p> </p>
<p>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.</p>
<p> </p>
<p>The guidance I've observed from the API working group is that any ISO 8601 timestamp format should be sufficient (<a href="https://review.openstack.org/#/c/159892/11/guidelines/time.rst" target="_blank">https://review.openstack.org/#/c/159892/11/guidelines/time.rst</a>).
 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.</p>
<p> </p>
<p>Thanks,</p>
<p> </p>
<p>Daryl</p>
</div>

__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>