Comment 7 for bug 1814245

Reviewed: https://review.openstack.org/637827
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=013f421bca4067bd430a9fac1e3b290cf1388ee4
Submitter: Zuul
Branch: stable/queens

commit 013f421bca4067bd430a9fac1e3b290cf1388ee4
Author: Matthew Booth <email address hidden>
Date: Fri Mar 9 14:41:49 2018 +0000

    Avoid redundant initialize_connection on source post live migration

    During live migration we update bdm.connection_info for attached volumes
    in pre_live_migration to reflect the new connection on the destination
    node. This means that after migration completes the BDM no longer has a
    reference to the original connection_info to do the detach on the source
    host. To address this, change I3dfb75eb added a second call to
    initialize_connection on the source host to re-fetch the source host
    connection_info before calling disconnect.

    Unfortunately the cinder driver interface does not strictly require that
    multiple calls to initialize_connection will return consistent results.
    Although they normally do in practice, there is at least one cinder
    driver (delliscsi) which doesn't. This results in a failure to
    disconnect on the source host post migration.

    This change avoids the issue entirely by fetching the BDMs prior to
    modification on the destination node. As well as working round this
    specific issue, it also avoids a redundant cinder call in all cases.

    Note that this massively simplifies post_live_migration in the libvirt
    driver. The complexity removed was concerned with reconstructing the
    original connection_info. This required considering the cinder v2 and v3
    use cases, and reconstructing the multipath_id which was written to
    connection_info by the libvirt fibrechannel volume connector on
    connection. These things are not necessary when we just use the original
    data unmodified.

    Other drivers affected are Xenapi and HyperV. Xenapi doesn't touch
    volumes in post_live_migration, so is unaffected. HyperV did not
    previously account for differences in connection_info between source and
    destination, so was likely previously broken. This change should fix it.

    NOTE(lyarwood): conflict due to Ibb8c12fb2799bb5ceb9e3d72a2b86dbb4f14451e
    not being present in stable/rocky.

    Conflicts:
            nova/tests/unit/compute/test_compute_mgr.py

    NOTE(lyarwood): Test conflicts due to the following changes landing in Rocky:
    If9993d5edab5a2f141387a8eb294a9645667ee6b,
    Ia9ea1e164fb3b4a386405538eed58d94ad115172,
    I3689dd6544c387676983be47cf925c3fd7ce72f1,
    I66762703709340a2f5c68dcd6802993c9a68c263. Additionally the backport
    only changes made to I0f3ab6604d8b79bdb75cf67571e359cfecc039d8 including
    the introduction of a configurable and removal of some tests from the
    original Rocky change also resulted in conflicts.

    Conflicts:
            nova/tests/unit/compute/test_compute.py
            nova/tests/unit/compute/test_compute_mgr.py

    Closes-Bug: #1754716
    Closes-Bug: #1814245
    Change-Id: I0390c9ff51f49b063f736ca6ef868a4fa782ede5
    (cherry picked from commit b626c0dc7b113365002e743e6de2aeb40121fc81)
    (cherry picked from commit 75e0f5a9b18293546db0ddf0fb073854e6704115)