Comment 8 for bug 1889108

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (stable/ussuri)

Reviewed: https://review.opendev.org/744162
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=034b2fa8fea0e34fed95a2ba728e4387ce4e78de
Submitter: Zuul
Branch: stable/ussuri

commit 034b2fa8fea0e34fed95a2ba728e4387ce4e78de
Author: Lee Yarwood <email address hidden>
Date: Mon Jul 27 19:27:24 2020 +0100

    compute: Don't delete the original attachment during pre LM rollback

    I0bfb11296430dfffe9b091ae7c3a793617bd9d0d introduced support for live
    migration with cinderv3 volume attachments during Queens. This initial
    support handled failures in pre_live_migration directly by removing any
    attachments created on the destination and reverting to the original
    attachment ids before re-raising the caught exception to the source
    compute. It also added rollback code within the main
    _rollback_live_migration method but missed that this would also be
    called during a pre_live_migration rollback.

    As a result after a failure in pre_live_migration
    _rollback_live_migration will attempt to delete the source host volume
    attachments referenced by the bdm before updating the bdms with the now
    non-existent attachment ids, leaving the volumes in an `available` state
    in Cinder as they have no attachment records associated with them
    anymore.

    This change aims to resolve this within _rollback_volume_bdms by
    ensuring that the current and original attachment_ids are not equal
    before requesting that the current attachment referenced by the bdm is
    deleted. When called after a failure in pre_live_migration this should
    result in no attempt being made to remove the original source host
    attachments from Cinder.

    Note that the following changes muddy the waters slightly here but
    introduced no actual changes to the logic within
    _rollback_live_migration:

    * I0f3ab6604d8b79bdb75cf67571e359cfecc039d8 reworked some of the error
      handling in Rocky but isn't the source of the issue here.

    * Ibe9215c07a1ee00e0e121c69bcf7ee1b1b80fae0 reworked
      _rollback_live_migration to use the provided source_bdms.

    * I6bc73e8c8f98d9955f33f309beb8a7c56981b553 then refactored
      _rollback_live_migration, moving the logic into a self contained
      _rollback_volume_bdms method.

    Closes-Bug: #1889108
    Change-Id: I9edb36c4df1cc0d8b529e669f06540de71766085
    (cherry picked from commit 2102f1834a6ac9fd870bfb457b28a2172f33e281)