block_device: Use the cinder attachment connection_info on detach - #655
Draft
leust wants to merge 1 commit into
Draft
block_device: Use the cinder attachment connection_info on detach#655leust wants to merge 1 commit into
leust wants to merge 1 commit into
Conversation
Nova detaches a volume with the connection_info it stashed in the BDM at attach time. Cinder is the authoritative source for that data, so the BDM copy can be stale by the time we detach. The case we hit in production is a volume that was migrated to the FCD driver behind nova's back: the BDM still says driver_volume_type 'vmdk' while cinder says 'fcd'. VMwareVolumeOps.detach_volume dispatches on driver_volume_type, so nova only notices the migration once the detach fails. Refresh the connection_info from the cinder attachment record before handing it to the virt driver. The multipath_id that os-brick found on this host and the multiattach flag are known to nova only, so they are preserved across the refresh. This is best-effort: if the attachment cannot be read or carries no connection_info, we keep using the BDM data as before, so an unreachable cinder does not turn into a failed detach. Only the local detach path is changed. driver_detach() as called from _remove_volume_connection() is left alone, because during live migration the BDM attachment is swapped between source and destination and refreshing there could hand a host the other host's connection_info. Change-Id: I662960d9a72057a6e976300314038001da2ff54e
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Nova detaches a volume with the connection_info it stashed in the BDM at attach time. Cinder is the authoritative source for that data, so the BDM copy can be stale by the time we detach.
The case we hit in production is a volume that was migrated to the FCD driver behind nova's back: the BDM still says driver_volume_type 'vmdk' while cinder says 'fcd'. VMwareVolumeOps.detach_volume dispatches on driver_volume_type, so nova only notices the migration once the detach fails.
Refresh the connection_info from the cinder attachment record before handing it to the virt driver. The multipath_id that os-brick found on this host and the multiattach flag are known to nova only, so they are preserved across the refresh.
This is best-effort: if the attachment cannot be read or carries no connection_info, we keep using the BDM data as before, so an unreachable cinder does not turn into a failed detach.
Only the local detach path is changed. driver_detach() as called from _remove_volume_connection() is left alone, because during live migration the BDM attachment is swapped between source and destination and refreshing there could hand a host the other host's connection_info.
Change-Id: I662960d9a72057a6e976300314038001da2ff54e