yahoo-eng-team team mailing list archive

[OpenStack Infra <1752115@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/549411
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=d2941bfd165055348dd584b630d4e631ef05e328
Submitter: Zuul
Branch:    master

commit d2941bfd165055348dd584b630d4e631ef05e328
Author: Matt Riedemann <mriedem.os@xxxxxxxxx>
Date:   Sat Mar 3 06:11:12 2018 -0500

    Pass user context to virt driver when detaching volume
    
    We need this in a later change to pull volume attachment
    information from cinder for the volume being detached so
    that we can do some attachment counting for multiattach
    volumes being detached from instances on the same host.
    
    Change-Id: I751fcb7532679905c4279744919c6cce84a11eb4
    Related-Bug: #1752115


** 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/1752115

Title:
  detach multiattach volume disconnects innocent bystander

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) queens series:
  In Progress

Bug description:
  Detaching a multi-attached lvm volume from one server, causes the
  other server to lose connectivity to the volume. I found this while
  developing a new tempest test to test this scenario.

  - create 2 instances on the same host, both simple instances with ephemeral disks
  - create a multi-attach lvm volume, attach to both instances
  - check that you can re-read the partition table from inside each instance (via ssh):

     $ sudo blockdev --rereadpt /dev/vdb

    This succeeds on both instances (no output or err message is
  returned).

  - detach the volume from one of the instances
  - recheck connectivity. The expected result is that the command will now fail in the instance where 
    the volume was detached. But it also fails on the instance where the volume is still supposedly 
    attached:

     $ sudo blockdev --rereadpt /dev/vdb
     BLKRRPART: Input/output error

  cinder & nova still think that the volume is attached correctly:

  $ cinder show 2cf26a15-8937-4654-ba81-70cbcb97a238 | grep attachment
  | attachment_ids                 | ['f5876aff-5b5b-45a0-a020-515ca339eae4']   

  $ nova show vm1 | grep attached
  | os-extended-volumes:volumes_attached | [{"id": "2cf26a15-8937-4654-ba81-70cbcb97a238", "delete_on_termination": false}] |

  cinder version:
    
  :/opt/stack/cinder$ git show
  commit 015b1053990f00d1522c1074bcd160b4b57a5801
  Merge: 856e636 481535e
  Author: Zuul <zuul@xxxxxxxxxxxxxxxxxxxx>
  Date:   Thu Feb 22 14:00:17 2018 +0000

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1752115/+subscriptions