[openstack-dev] [nova] looking for feedback on object versioning

Sylvain Bauza sbauza at redhat.com
Mon Mar 16 09:23:13 UTC 2015

Le 14/03/2015 01:13, Chris Friesen a écrit :
> Hi,
> I've recently submitted some code for review at 
> "https://review.openstack.org/163060".
> The change involves adding a new "reported_at" field to the Service 
> object class, and I'd like some feedback on the object-versioning 
> aspects of that:
> 1) Do I need to do anything special in obj_make_compatible()?

Yes, you need to make sure that you won't provide the new field to a 
previous version of Service object.
See other examples on other objects to see how to do this.
> 2) Is what I've done in _from_db_object() correct?  If I don't do it 
> like this, how is the "reported_at" field handled when a node sends a 
> v1.11 version of the object (or the corresponding dict) to another 
> node that wants a v1.12 version object?

_from_db_object is called for transforming a DB services table SQLA 
object (ie. a tuple) into a NovaObject Service object.
By saying that you won't check it, it means that you won't have it 
persisted on the DB table.

That's possible, but then you have to make sure you can either lazy-load 
or have a Service property for the field so that you'll be able to value 
the field.

About the compatibilty, that's quite simple : if an old v1.11 Service 
object is sending its values to a v1.12 Service object, it won't have 
the field set until someone is lazy-loading the new field or calling a 

> 3) Is it okay to lazy-load a "None" value in obj_load_attr()?  The 
> nice thing about doing it this way is that a large number of 
> unit/functional tests can stay as-is.

No, that's not acceptable. The goal of obj_load_attr() is to lazy-load 
fields by setting their values on the object. You should not return 
anything but instead make sure that self.reported_at field is set.

Honestly, the patch is really big for being reviewed. I also have some 
concerns about how you plan to fix the bug by adding a new field which 
is not persisted, but I prefer to leave my comments on Gerrit, that's 
what it's used for :-)


> Thanks,
> Chris
> __________________________________________________________________________ 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list