Open Stack

Hi Monty,

On Wed, Jul 5, 2017 at 6:05 PM, Monty Taylor <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/95e444f257b7f0
> be982616292475a6e4aaed0fe0/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/d5eda9707e14
>> 6108e4d424062b602fd97a71c2e6/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/?ex
>> panded=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 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.

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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k-api-consumers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-api-consumers/attachments/20170706/cc8ecc07/attachment.html>