Missing relationship maps in Versioned Objects

[Gorka Eguileor]

With current code when running in pinned mode (during rolling upgrades) we may get exception like this:

ERROR cinder.api.middleware.fault File "/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 436, in _obj_relationship_for
ERROR cinder.api.middleware.fault reason='No rule for %s' % field)
ERROR cinder.api.middleware.fault ObjectActionError: Object action obj_make_compatible failed because: No rule for volume_type

Because we don't use manifests or relationship maps to let Oslo Versioned Object backporting know which version of the ObjectField fields must be used for the backport.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/307075

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/325143

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/307075
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=f0d34b7d9ba79af1b50c1e89e2cd3493075c2754
Submitter: Jenkins
Branch: master

commit f0d34b7d9ba79af1b50c1e89e2cd3493075c2754
Author: Gorka Eguileor <email address hidden>
Date: Thu Apr 14 20:52:36 2016 +0200

    Use manifest to backport OVOs during upgrades

    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

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/cinder 9.0.0.0b2 development milestone.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/325143
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=c3471fc38a1d6d855559d15fce5b39e74c9eb792
Submitter: Jenkins
Branch: stable/mitaka

commit c3471fc38a1d6d855559d15fce5b39e74c9eb792
Author: Gorka Eguileor <email address hidden>
Date: Thu Apr 14 20:52:36 2016 +0200

    Use manifest to backport OVOs during upgrades

    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
    (cherry picked from commit f0d34b7d9ba79af1b50c1e89e2cd3493075c2754)

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/cinder 8.1.0 release.