I was looking through Nova Objects with a view to creating an extensible object that can be used by writers of plugins to include data generated by the plugin (others have also done the same e.g. https://review.openstack.org/#/c/65826/ ) On the way I noticed what I think is a bug in Nova Objects serialization (but might be considered "by design" by some - see: https://bugs.launchpad.net/nova/+bug/1275675). 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.
Now this is not a problem if the version of A is always bumped when the version of B changes. If the A and B versions are always deployed together, because they are revised and built together, then A will always be the one that is found to be incompatible first and in back porting it will always know what version its child should be. If that is not the way things are meant to work then there is a problem (I think). Going back to the extensible object, what I would like to be able to do is allow the writer of a plugin to implement a nova object for data specific to that plugin, so that it can be communicated by Nova. (For example, a resource plugin on the compute node generates resource specific data that is passed to the scheduler, where another plugin consumes it). This object will be communicated as a child of another object (e.g. the compute_node). It would be useful if the plugins at each end benefit from the same version handling that nova does itself. 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. 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. Another might be to say that nova objects are for nova use only and that's just tough for plugin writers! Thoughts? Paul Paul Murray HP Cloud Services +44 117 312 9309 Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England. The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL".
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
