[1] https://review.opendev.org/#/c/638046/56/nova/conductor/tasks/cross_cell_migrate.py@899
[2] https://review.opendev.org/#/c/638046/56/nova/conductor/tasks/cross_cell_migrate.py@1160
[3] https://review.opendev.org/#/c/638046/56/nova/conductor/tasks/cross_cell_migrate.py@1187
[4] https://review.opendev.org/#/c/695334/5/nova/conductor/tasks/cross_cell_migrate.py@1464
[5] https://review.opendev.org/#/c/638048/56/nova/tests/functional/test_cross_cell_migrate.py@570
[6] https://review.opendev.org/#/c/638269/63/nova/compute/api.py@3735
[7] https://review.opendev.org/#/c/691991/15/nova/objects/migration_context.py@131
[8] https://review.opendev.org/#/c/638268/56/nova/tests/functional/test_cross_cell_migrate.py@762

Part of blueprint cross-cell-resize

Change-Id: I92a7c0c35415661db16edb89dc860f4512b98316

When migrating a non-volume-backed server across cells we will
create a temporary snapshot image and use that to spawn the
guest in the destination host/cell (like unshelve) and then
_finish_snapshot_based_resize_at_dest in the ComputeManager
will attempt to delete the snapshot image. For rbd images,
deleting the snapshot image will fail if we don't flatten it
first.

This builds on If3c9d1de3ce0fe394405bd1e1f0fa08ce2baeda8 and
adds logic to the libvirt driver such that, like the unshelve
scenario, if we are doing a cross-cell move we flatten the rbd
image so the ComputeManager can delete the temporary snapshot
image after the guest is spawned.

Part of blueprint cross-cell-resize

Change-Id: If56842da51688476072814e6e8309cf9e0a0210c

Introduce Resource and ResourceList objects, and add new resources
field to instance, also old_/new_ resources fields to migration_context,
Resource object can contain a generic resource information.

Change-Id: I095bb71d2a5e451f2827f646aa5b3ed31d2ccac3
Partially-Implements: blueprint virtual-persistent-memory
Co-Authored-By: He Jie Xu <hejie.xu@intel.com>

In order to fix Bug #1809095, it is required to update
PCI related VIFs with the original PCI address on the source
host to allow virt driver to properly unplug the VIF from hypervisor,
e.g allow the proper VF representor to be unplugged
from the integration bridge in case of a hardware offloaded OVS.

To do so, some preliminary work is needed to allow code-sharing
between nova.network.neutronv2 and nova.compute.manager

This change:
- Moves common logic to retrieve the PCI mapping between
  the source and destination node from nova.network.neutronv2
  to objects.migration_context.
- Makes code adjustments to methods in nova.network.neutronv2
  to accomodate the former.

Change-Id: I9a5118373548c525b2b1c2271e7d210cc92e4f4c
Partial-Bug: #1809095

nova/db/__init__.py was importing * from nova.db.api. This meant that
any time any code anywhere within the nova.db package was imported
then nova.db.api was too, leading to a cascade of imports that may
not have been desired. Also, in general, code in __init__.py is a pain.

Therefore, this change adjusts code that so that either:

* nova.db.api is used directly
* nova.db.api is imported as 'db'

In either case, the functionality remains the same.

The primary goal of this change was to make it possible to import the
model files without having to import the db api. Moving the model files
to a different place in the directory hierarchy was considered, but
given that "code in __init__.py is a pain" this mode was chosen.

This looks like a very large change, but it is essentially adjusting
package names, many in mocks.

Change-Id: Ic1fd7c87ceda05eeb96735da2a415ef37060bb1a

When resizing guest to flavor with pci passthrogth, we need to drop
the old pci devices and allocate new ones. To be able to do that we
are leveraging the migration context (that used only for NUMA).

Adds old and new PCI devices/ PCI requests into the MigrationContext
object and uses the nova.pci.request.get_pci_requests_from_flavor()
function to grab the set of requested PCI devices during a migration.

Then, in the resource tracker's _update_usage_from_migration() call, we
use the old and new PCI devices and PCI requests stored in the
MigrationContext to properly account for changes.

Closes-Bug: #1368201
Co-Authored-by: Jay Pipes <jaypipes@gmail.com>

Change-Id: Ie8690f2b7235d677ebe15fabaae81b0a6bda29de

Currently, changes to instance fields backed by instance_extras table
trigger separate db calls for each individual change when calling
save() on the instance. This reworks that so that all changes gets
saved with a single call to the db.

Change-Id: I2ddcb625ca54f18b1a68f8ddd1f28e541f438a74

In Liberty, we converted to using the manifest-based class
action and backport methods, which no longer rely on these
object relationship maps. They provide a full manifest of
client-side versions with each call, which is far more
robust than us trying to hand-edit these mappings (which
we get incorrect a lot).

Since we're now in Mitaka, we can drop compatibility with
clients that don't make the version-manifest calls. Those
have also been deprecated in oslo.versionedobjects.

Change-Id: Iea8b6348e3b01aaa335ec5408f07826f1e758d20

Part of the object infrastructure needed for

Change-Id: I877483931867ecc64f142f4950655725643aa802
Related-blueprint: migration-fix-resource-tracking