Open Stack

> 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