Open Stack

On 07/06/2017 08:48 PM, Joe Topjian wrote:
> Hi Monty,
> 
> On Wed, Jul 5, 2017 at 6:05 PM, Monty Taylor <mordred at inaugust.com 
> <mailto:mordred at inaugust.com>> wrote:
> 
>     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
>     <https://github.com/openstack-infra/shade/blob/95e444f257b7f0be982616292475a6e4aaed0fe0/shade/operatorcloud.py#L2122-L2183>
> 
> 
> Thanks - this is good to know!
> 
>         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
>         <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
>         <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
>     <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
>         <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 see the merits of this, as well as parsing any iso8601 format in 
> general for fields that are designed to be iso8601.
> 
>     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. :)
> 
> 
> I looked over all of this again. You're right about iso8601 being 
> lenient -- it covers a wide range of formats. Go does not have a 
> standard time parser like python's iso8601 module, which is unfortunate.

Maybe we can convince someone to write a go iso8601 library. (I know I 
certainly don't want to write a date/time parsing library myself- that's 
a road to madness! :) )

> It does have some RFC3339 constants 
> (https://golang.org/pkg/time/#pkg-constants), and I think that's where 
> some confusion has crept in. RFC3339 requires some type of time zone 
> notation.
> 
> 
>         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.
> 
> 
> No problem at all - thanks for the info!
> 
> 
>     Monty
> 
>     _______________________________________________
>     Openstack-api-consumers mailing list
>     Openstack-api-consumers at lists.openstack.org
>     <mailto:Openstack-api-consumers at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-api-consumers
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-api-consumers>
> 
>