[openstack-dev] [nova] looking for feedback on object versioning
sbauza at redhat.com
Mon Mar 16 09:23:13 UTC 2015
Le 14/03/2015 01:13, Chris Friesen a écrit :
> I've recently submitted some code for review at
> 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
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 :-)
> OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev