Version change in ObjectField does not work with back-levelling

[Paul Murray]

When a NovaObject primitive is deserialized the object version is checked and an IncompatibleObjectVersion exception is raised if the serialized primitive is labelled with a version that is not known locally. The exception indicates what version is known locally, and the deserialization attempts to backport the primitive to the local version.

If a NovaObject A has an ObjectField b containing NovaObject B and it is B that has the incompatible version, the version number in the exception will be the the locally supported version for B. The desrialization will then attempt to backport the primitive of object A to the locally supported version number for object B.

[Paul Murray (pmurray)]

The following test demonstrates the bug:

given these class versions:

class Container(base.NovaObject):
    VERSION = '5.5'
    fields = {
        'nested': fields.ObjectField('MyObj'),
    }

class MyObj(base.NovaPersistentObject, base.NovaObject):
    VERSION = '1.5'
<...rest of object code cut out...>

The following test passes:

    def test_deserialize_nested_object(self):
        ser = base.NovaObjectSerializer()
        ser._conductor = mock.Mock()
        ser._conductor.object_backport.return_value = 'backported'
        A = Container()
        B = MyObj()
        A.nested = B
        B.VERSION = '1.25'
        primitive = A.obj_to_primitive()
        result = ser.deserialize_entity(self.context, primitive)
        self.assertEqual('backported', result)
        ser._conductor.object_backport.assert_called_with(self.context,
                                                          primitive,
                                                          '1.5')

So _conductor.object_backport is being called with the primitive of A and the version number of B.

[Matt Riedemann (mriedem)]

I think this was brought up here:

http://lists.openstack.org/pipermail/openstack-dev/2014-February/026151.html

[Paul Murray (pmurray)]

As suggested here: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026151.html the deserializer could indicate to conductor which object is the problem and allow it to attempt a conversion on that object. That could be a useful thing to do, but is not part of the original design and out of scope right now. In particular the object code currently assumes that the object versions line up correctly when nesting objects.

This bug should not surface if code is written and tested correctly, but its easy to check for so I'll propose the following fix to close it.

1. Add new exception NestedObjectVersionError for this error condition.
2. When the deserializer receives the IncompatibleObjectVersionError exception it checks to see it refers to the top level prim object itself. If it doesn't the exception comes from an incorrect nested object, so raise a new exception inidicating this condition.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/78605

[OpenStack Infra (hudson-openstack)]

Change abandoned by Paul Murray (<email address hidden>) on branch: master
Review: https://review.openstack.org/78605
Reason: Actually, I'll just abandon it.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/202554

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/202560

[OpenStack Infra (hudson-openstack)]

Change abandoned by Nikola Dipanov (<email address hidden>) on branch: master
Review: https://review.openstack.org/202554
Reason: Will abandon for a more optimal fix that does not potentially send more than one backleveling request for a highly nested structure

[OpenStack Infra (hudson-openstack)]

Change abandoned by Nikola Dipanov (<email address hidden>) on branch: stable/kilo
Review: https://review.openstack.org/202560

[Markus Zoeller (markus_z) (mzoeller)]

This is now over 2 years old and the comments in [1] indicate that this is the responsibility of "oslo.versionedobjects" now. The ML discussion [1] doesn't show a clear path forward neither. I'm closing it as "won't fix".

References:
[1] https://review.openstack.org/#/c/202554/
[2] http://lists.openstack.org/pipermail/openstack-dev/2014-February/026151.html

[Ben Nemec (bnemec)]

Setting to wishlist, per the original nova bug. However, as the bug is years old, can we verify that it is still present in current versions of o.vo?

[Launchpad Janitor (janitor)]

[Expired for oslo.versionedobjects because there has been no activity for 60 days.]