Open Stack

On 06/21/2017 11:13 PM, Joe Topjian wrote:
> Hello,
> 
> I'm Joe and I do a lot of work with OpenStack and Go. Since Go is a 
> rather strict language, it's easy to run into inconsistencies both 
> between different OpenStack services as well as what the OpenStack API 
> docs mention. So some of the things I'll be posting here are to ask for 
> clarification on such findings :)

\o/ (sorry for the delay - somehow this list got filtered wrong. DOH)

> I was wondering if someone could provide some information as to how time 
> is handled in OpenStack.
> 
> Nova, Neutron, and Glance all seem to represent time in the following 
> format:
> 
> "updated_at": "2017-05-17T22:59:18Z"
> 
> This looks to be a standard ISO8601 UTC format.

Yes. Although it should be noted that one cannot SEND full ISO8601 
compliant strings - they may only be the above UTC format with no offset 
listed.

https://github.com/openstack-infra/shade/blob/95e444f257b7f0be982616292475a6e4aaed0fe0/shade/operatorcloud.py#L2122-L2183

> On the other hand, Cinder and Designate have the following format:
> 
> "created_at": "2017-02-28T16:58:09.000000"
> 
> In Gophercloud, the above format is titled RFC3339MilliNoZ:
> 
> https://github.com/gophercloud/gophercloud/blob/d5eda9707e146108e4d424062b602fd97a71c2e6/results.go#L224-L242
> 
> I'll also note that the created_at and updated_at fields in the API 
> reference for Cinder have the date format as ISO8601:
> 
> https://developer.openstack.org/api-ref/block-storage/v3/?expanded=show-a-volume-s-details-detail#show-a-volume-s-details
> 
> Unless I'm mistaken, and I am not an expert on time standards, that's 
> not correct? Someone has even mentioned that the lack of Z or any time 
> zone notation is invalid ISO8601 to begin with
Wikipedia says: (I can't afford to buy the actual ISO spec) "Decimal 
fractions may be added to any of the three time elements. However, a 
fraction may only be added to the lowest order time element in the 
representation."

https://en.wikipedia.org/wiki/ISO_8601

The trailing Z is also optional. If it's not there, the time is supposed 
to be assumed to be in "local time". Now - I'm pretty sure that makes NO 
sense in this context - so although it's a 'correct' iso8601, I'm pretty 
sure it's communicating something incorrect - or incomplete.

> Having different formats isn't a *huge* deal. A note can be filed and 
> the different formats per service can be managed. Where this gets 
> interesting is in the following discussion:
> 
> https://github.com/gophercloud/gophercloud/issues/248
> 
> tl;dr: Someone has written a Block Storage compatible API service. This 
> service is returning dates in the ISO8601 format. Gophercloud is giving 
> an error because it is expecting the date format to be in that 
> milli-no-z format like in the "official" Block Storage service (Cinder).
> 
> But that user is able to use OSC on their API service and it works just 
> fine.
 >
> So it seems the Python SDK/client is being lenient on the date format. 
> Is that accurate? If so, why?

The iso8601 python module parses both just fine:

 >>> iso8601.iso8601.parse_date("2017-05-17T22:59:18Z")
datetime.datetime(2017, 5, 17, 22, 59, 18, tzinfo=<iso8601.Utc>)
 >>> iso8601.iso8601.parse_date("2017-02-28T16:58:09.000000")
datetime.datetime(2017, 2, 28, 16, 58, 9, tzinfo=<iso8601.Utc>)

and as mentioned above, it's technically valid iso8601 - concerns about 
the lack of Z communicating something very weird notwithstanding.

I would argue with the cioa person that if they have a service that has 
"implemented a subset of the cinder api" and that service is returning a 
different format timestamp than cinder, that they have not, in fact, 
implemented a subset of the cinder API. OpenStack isn't an API spec - 
it's an implementation. So cinder's behavior IS the de-facto correct 
behavior.

But that's not helpful - I think you'll be better off making sure you 
can parse either format as input. I would also not count on the data 
from cinder _always_ being in RFC3339MilliNoZ. The intent, AIUI, is for 
cinder to return iso8601 - which is remarkably lenient. :)
> As well, what time formats should be officially and confidently 
> supported across all services? I'm not the kind of person who gets hung 
> up on specifics, but having to add support for multiple formats just in 
> case one of those is returned feels a little disorganized.

Yah. Agree. So far I'm not aware of any date/time formats that are not 
parseable by the python8601 module. The two you've mentioned here are 
the two most common forms I've seen.

Sorry for the delay responding.

Monty