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
2102f1834a