> Basically, if object A has object B as a child, and deserialization > finds object B to be an unrecognized version, it will try to back > port the object A to the version number of object B.
Right, which is why we rev the version of, say, the InstanceList when we have to rev Instance itself, and why we have unit tests to makes sure that happens. > It is not reasonable to bump the version of the compute_node when > new external plugin is developed. So currently the versioning seems > too rigid to implement extensible/pluggable objects this way. So we're talking about an out-of-tree closed-source plugin, right? IMHO, Nova's versioning infrastructure is in place to make Nova able to handle upgrades; adding requirements for supporting out-of-tree plugins wouldn't be high on my priority list. > A reasonable alternative might be for all objects to be deserialized > individually within a tree data structure, but I’m not sure what > might happen to parent/child compatability without some careful > tracking. I think it would probably be possible to make the deserializer specify the object and version it tripped over when passing the whole thing back to conductor to be backleveled. That seems reasonably useful to Nova itself. > Another might be to say that nova objects are for nova use only and > that’s just tough for plugin writers! Well, for the same reason we don't provide a stable virt driver API (among other things) I don't think we need to be overly concerned with allowing arbitrary bolt-on code to hook in at this point. Your concern is, I assume, allowing a resource metric plugin to shove actual NovaObject items into a container object of compute node metrics? Is there some reason that we can't just coerce all of these to a dict-of-strings or dict-of-known-primitive-types to save all of this complication? I seem to recall the proposal that led us down this road being "store/communicate arbitrary JSON blobs", but certainly there is a happy medium? Given that the nova meetup is next week, perhaps that would be a good time to actually figure out a path forward? --Dan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
