f0d34b7d9b
To make objects that have other objects as fields compatible to an earlier version, oslo versioned objects uses either a manifest passed to obj_to_primitive or the object's obj_relationships mapping. Which means that if we don't have any of those mechanisms in place our rolling upgrades mechanism will fail whenever we try to backport a Versioned Object that has set an ObjectField field because Oslo Versioned Object will not know how to backport that related object. This patch introduces the usage of manifests on backports when we are doing rolling upgrades. For the manifest, we use the data in our Objects History. Which means that as long as we keep history in OBJ_VERSIONS right we will not have to create and worry about keeping lists' child_versions field or our versioned object's obj_relationships for fields with types ListOfObjectsField and ObjectField. We also don't have to worry about cascade version bumping, as in changing the List OVO version whenever the OVO it contains gets bumped, or bumping our OVO whenever one of the related OVO fields is bumped. Closes-Bug: #1571566 Change-Id: Ibc1a1257830c925c10696c0b5aedd5f471c538d0
CINDER
You have come across a storage service for an open cloud computing service. It has identified itself as Cinder. It was abstracted from the Nova project.
- Wiki: http://wiki.openstack.org/Cinder
- Developer docs: http://docs.openstack.org/developer/cinder
Getting Started
If you'd like to run from the master branch, you can clone the git repo:
For developer information please see HACKING.rst
You can raise bugs here http://bugs.launchpad.net/cinder
Python client
https://git.openstack.org/cgit/openstack/python-cinderclient