yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #76972
[Bug 1754716] Re: Disconnect volume on live migration source fails if initialize_connection doesn't return identical output
Reviewed: https://review.openstack.org/551302
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=b626c0dc7b113365002e743e6de2aeb40121fc81
Submitter: Zuul
Branch: master
commit b626c0dc7b113365002e743e6de2aeb40121fc81
Author: Matthew Booth <mbooth@xxxxxxxxxx>
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.
Closes-Bug: #1754716
Closes-Bug: #1814245
Change-Id: I0390c9ff51f49b063f736ca6ef868a4fa782ede5
** Changed in: nova
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1754716
Title:
Disconnect volume on live migration source fails if
initialize_connection doesn't return identical output
Status in OpenStack Compute (nova):
Fix Released
Bug description:
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 we no
longer have a reference to the original connection_info to do the
detach on the source host, so we have to re-fetch it with a second
call to initialize_connection 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1754716/+subscriptions
References