Live upgrade from Havana broken by commit 62e9829

[Dan Smith]

Commit 62e9829 inadvertently broke live upgrades from Havana to master. This was not really related to the patch itself, other than that it bumped the Instance version which uncovered a bunch of issues in the object infrastructure that weren't yet ready to handle this properly.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/60322

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/60323

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/60322
Committed: http://github.com/openstack/nova/commit/21438085c8e37bc102d6858511670aec35cc73aa
Submitter: Jenkins
Branch: master

commit 21438085c8e37bc102d6858511670aec35cc73aa
Author: Dan Smith <email address hidden>
Date: Thu Dec 5 09:05:32 2013 -0800

    Make obj_from_primitive() preserve version information

    When we hydrate an object from a remote client, we need to know
    the version and not pretend like it's just the current version.

    Related-Bug: #1258256
    Change-Id: I68bbfa18addfb7e51efc10a757135e338302a787

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/60323
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=28bd2298baf59d37c9020087aa7b3fef07504aa6
Submitter: Jenkins
Branch: master

commit 28bd2298baf59d37c9020087aa7b3fef07504aa6
Author: Dan Smith <email address hidden>
Date: Thu Dec 5 09:38:17 2013 -0800

    Don't replace instance.info_cache on each save

    If we are working on an Instance that came from an older client,
    we should not replace an older nested .info_cache object with a
    newer one for no reason during a save().

    Related-Bug: #1258256
    Change-Id: I8cf4a629d454de1a5de16ea4032f39e36aab505a

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/58398
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ff221c6cc61f7b98b62462ab4f0e0e1cf691a9a8
Submitter: Jenkins
Branch: master

commit ff221c6cc61f7b98b62462ab4f0e0e1cf691a9a8
Author: Dan Smith <email address hidden>
Date: Mon Nov 25 14:48:26 2013 -0800

    Require List objects to be able to backlevel their contents

    Right now, a client declares its supported version of a given object
    automatically in the remoted calls it makes to conductor. However,
    in the case of things like InstanceList.get_by_foo(), they are
    reporting the version of their InstanceList object, not their
    Instance object. Conductor fills a version-matching InstanceList
    object with brand new Instance objects, which the client, of course,
    barfs on.

    There may be a better way to handle this going forward, but for now,
    stop the bleeding by requiring a version bump to the corresponding
    List object whenever the object type it contains takes a version
    bump. This adds a test to validate that all the objects registered
    have a suitable mapping for the current version in the tree.

    Since this actually caused a breakage in the Instance object
    recently, this also bumps the InstanceList version so that
    conductors running this commit (or later) will properly send
    version 1.9 Instance objects to Havana clients and version 1.10+
    to newer ones.

    Change-Id: I2668dead4784fbd0411d1b6372a9a8006eeb2e84
    Related-Bug: #1258256
    Closes-Bug: #1254902

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/havana
Review: https://review.openstack.org/62454

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/59560
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=0eb7e35fbfe5de5f9f00ff1a0cce1d6a61f3a902
Submitter: Jenkins
Branch: master

commit 0eb7e35fbfe5de5f9f00ff1a0cce1d6a61f3a902
Author: Dan Smith <email address hidden>
Date: Mon Dec 2 12:25:04 2013 -0800

    Make Serializer/Conductor able to backlevel objects

    This improves handling the situation where nova-api sends newer
    objects to an older compute node. In this case, the serializer detects
    the IncompatibleObjectVersion error and asks conductor to backlevel it.
    This means we call into a new method in conductor with the primitive
    object that we can't handle, and basically ask it to hydrate it and
    call obj_make_compatible() on our behalf and pass it back to us.

    This eliminates the need for API to know whether it's talking to
    an older compute and allows a newer conductor to assist older
    compute nodes during upgrades to a significant degree.

    Related-Bug: #1258256
    Change-Id: I4b17c8382619e4f73b83c026bf68549ac67a68a2

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/62454
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=81af1ab488930b511cac056cdc4ac2a8a26f0d7b
Submitter: Jenkins
Branch: stable/havana

commit 81af1ab488930b511cac056cdc4ac2a8a26f0d7b
Author: Dan Smith <email address hidden>
Date: Mon Dec 2 12:25:04 2013 -0800

    Make Serializer able to backlevel objects

    This improves handling the situation where nova-api sends newer
    objects to an older compute node. In this case, the serializer detects
    the IncompatibleObjectVersion error and asks conductor to backlevel it.
    This means we call into the conductor with the primitive object that we
    can't handle, and basically ask it to hydrate it and call
    obj_make_compatible() on our behalf and pass it back to us.

    This eliminates the need for API to know whether it's talking to
    an older compute and allows a newer conductor to assist older
    compute nodes during upgrades to a significant degree.

    Adapted for havana/stable from master commit: 0eb7e35

    Related-Bug: #1258256
    Change-Id: I4b17c8382619e4f73b83c026bf68549ac67a68a2