> On a compute manager that is still running the old version of the code > (i.e using the previous object version), if a method that hasn’t yet > been converted to objects gets a dict created from the new version of > the object (e.g. rescue, get_console_output), then object_compat() > decorator will call the _/from_db/_object() method in > objects.Instance. Because this is the old version of the object > code, it expects user_data to be a field in dict, and throws a key error.
Yeah, so the versioning rules are that for a minor version, you can only add things to the object, not remove them. > 1) Rather than removing the user_data field from the object just > set it to a null value if its not requested. Objects have a notion of "unset" which is what you'd want here. Fields that are not set can be lazy-loaded when touched, which might be a reasonable way out of the box here if user_data is really only used in one place. It would mean that older clients would lazy-load it when needed, and going forward we'd be specific about asking for it when we want. However, the problem is that instance defines the fields it's willing to lazy-load, and user_data isn't one of them. That'd mean that we need to backport a change to allow it to be lazy-loaded, which means we should probably just backport the thing that requests user_data when needed instead. > 2) Add object versioning in the client side of the RPC layer for > those methods that don’t take objects. I'm not sure what you mean here. > I’m open to other ideas, and general guidance around how deletion of > fields from Objects is meant to be handled ? It's meant to be handled by rev-ing the major version, since removing something isn't a compatible operation. Note that *conductor* has knowledge of the client-side version of an object on which the remotable_classmethod is being called, but that is not exposed to the actual object implementation in any way. We could, perhaps, figure out a sneaky way to expose that, which would let you honor the old behavior if we know the object is old, or the new behavior otherwise. --Dan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev