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 |
||
|---|---|---|
| .. | ||
| drivers | ||
| __init__.py | ||
| fake_backup.py | ||
| fake_google_client.py | ||
| fake_google_client2.py | ||
| fake_service.py | ||
| fake_service_with_verify.py | ||
| fake_swift_client.py | ||
| fake_swift_client2.py | ||
| test_backup.py | ||
| test_rpcapi.py | ||