The tl;dr is to 1) avoid trying to disconnect volumes on the
destination if they were never connected in the first place and
2) avoid trying to disconnect volumes on the destination using block
device info for the source.
Details:
* Only remotely disconnect volumes on the destination if the failure
was not during pre_live_migration(). When pre_live_migration() fails,
its exception handling deletes the Cinder attachment that was created
before re-raising and returning from the RPC call. And the BDM
connection_info in the database is not guaranteed to reference the
destination because a failure could have happened after the Cinder
attachment was created but before the new connection_info was saved
back to the database. In this scenario, there is no way to reliably
disconnect volumes in the destination remotely from the source because
the destination connection_info needed to do it might not be
available.
* Due to the first point, this adds exception handling to disconnect
the volumes while still on the destination, while the destination
connection_info is still available instead of trying to do it
remotely from the source afterward.
* Do not pass Cinder volume block_device_info when calling
rollback_live_migration_on_destination() because volume BDM records
have already been rolled back to contain info for the source by
that point. Not passing volume block_device_info will prevent
driver.destroy() and subsequently driver.cleanup() from attempting to
disconnect volumes on the destination using connection_info for the
source.
Closes-Bug: #1899835
Change-Id: Ia62b99a16bfc802b8ba895c31780e9956aa74c2d
5a55a78d51