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

Chris Friesen chris.friesen at windriver.com
Tue Mar 17 15:24:10 UTC 2015

On 03/16/2015 03:23 AM, Sylvain Bauza wrote:
> Le 14/03/2015 01:13, Chris Friesen a écrit :
>> 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.

Okay, that makes sense.

>> 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.

Would it be possible to have a case where a v1.12 Service object calls 
_from_db_object() where the argument is a DB object that hasn't been upgraded 
yet?  (Like maybe if we upgraded nova-compute before nova-conductor?)

If so, then it seems like either we implicitly set it as "None" in 
_from_db_object(), or else allow it to be lazy-loaded as "None" in obj_load_attr().

>> 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.

Whoops, the return is a clear bug.  Would it be okay to set "self.reported_at = 
None" in obj_load_attr()?

> 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 :-)

I'm not sure what you mean here.  Are you suggesting that it should be broken 
into multiple patches?

Thanks for taking a look at this.


More information about the OpenStack-dev mailing list