Open Stack

On 06/03/2013 09:14 AM, Doug Hellmann wrote:
> 
> 
> 
> On Mon, Jun 3, 2013 at 7:33 AM, Flavio Percoco <flavio at redhat.com
> <mailto:flavio at redhat.com>> wrote:
> 
>     Hi,
> 
>     I'm planning to re-factor current Oslo's jsonutils module and as part
>     of that re-factor process I'd like to add a better support for datetimes
>     objects.
> 
>     Before going further with the implementation, I'd like to get some
>     feedback from folks and see if any of you have already done it or at
>     least thought about it.
> 
>     Currently jsonutils serializes datetimes using timeutils.strtime
>     function, which returns a ISO8601 formatted string. Since this is a
>     string, there's no easy way to understand, when de-serializing,
>     whether it is a datetime, was a datetime before and / or should be
>     de-serialized as datetime.
> 
>     The first point is:
> 
>     1) Do we really need this?
>             From a "compatibiliy" POV I'd prefer not having it and avoid
>         sending datetimes that are supposed to be de-serialized. However,
>         there are definitely cases were this is useful and makes
>         implementations way easier.
> 
>     2) Does it make sense to have this in Oslo?
> 
>         My bet is yes. We currently need it in Glance and I think other
>         projects can benefit from this - nova does something similar. (We
>         can use Glance as a POC for this).
> 
> 
>     3) I've put some thoughts on it that I'd like to share:
> 
>         1) Try always to convert the str to datetime - using
>         timeutils.parse_strtime. The drawback is that we might convert to
>         datetimes values that weren't datetime before being serialized.
>         Similar to what nova's sqlalchemy api does[0].
> 
>         2) Add a prefix / suffix to the serialized datetime. This will
>         allow the de-serializer to know whether it should be converted to
>         datetime.
> 
>         3) Serialize the datetime as a dictionary with the following
>         structure:
> 
>             {"_type": "datetime",          "_value": "....",        
>      "_format": "%Y-%m-%dT%H:%M:%S.%f"}
>                 The above will allow the de-serializer to know whether it
>             should be converted, the object type (datetime, date or time)
>             and the format it was serialized with. I don't like this idea
>             but I see the benefit of having all that information.
> 
> 
> You could also just include the _type and _value, leaving the
> interpretation of that value up to the receiver.
> 
> At the summit there was a proposal in the nova track to support sending
> arbitrary objects over RPC transparently as part of the versioned object
> session [1]. I think the final proposal involved using a registry of
> types with serializers and deserializers. Datetimes could just be
> another type in that registry system.

Yes, and I would encourage any and all projects affected by this to go
down a similar path.  This project is well under way.

  https://blueprints.launchpad.net/nova/+spec/rpc-support-for-objects

  https://blueprints.launchpad.net/nova/+spec/unified-object-model

As for the current jsonutils code, I would just leave it how it is and
avoid making any format changes.  It's going to break backwards
compatibility for code that uses it right now.

-- 
Russell Bryant