yahoo-eng-team team mailing list archive

[OpenStack Infra <1703954@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/528694
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=3b01eb78ce1c1ce388521f8122b3d6b8f2686fda
Submitter: Zuul
Branch:    master

commit 3b01eb78ce1c1ce388521f8122b3d6b8f2686fda
Author: Gorka Eguileor <geguileo@xxxxxxxxxx>
Date:   Fri Dec 15 12:09:41 2017 +0100

    Fix create encrypted volume from image
    
    If we run two create encrypted volume from image serially (waiting for
    one operation to complete before the making the next request) the first
    operation succeeds while the second one will fail during the attach
    phase.
    
    The failure we see in the logs indicate that OS-Brick is unable to get
    the WWN from the connected volume.
    
    In reality the failure to attach the volume on the second operation is
    caused by a failed cleanup of the first create, even if there's no error
    in the logs.
    
    The reason why OS-Brick didn't correctly do the cleanup of the first
    volume is because didn't know that it was attaching an encrypted volume
    and returned a real path (ie: /dev/sdf) that then go overwritten by the
    unencrypted device mapper.
    
    The solution is letting OS-Brick know that it's an encrypted volume
    during the attachment phase so it will return a symlink to the real
    device instead of the real device itself.
    
    The manager's "initialize_connection" does this correctly, but the
    method creating the volume from an image doesn't use the method of that
    class and calls the driver's "initialize_connection" method instead,
    which is missing the "encrypted" field.
    
    Closes-Bug: #1703954
    Change-Id: I35db18f36f86683f2ab16694c9787c908251a382


** Changed in: cinder
       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/1703954

Title:
  Attach/Detach encrypted volume problems with real paths

Status in Cinder:
  Fix Released
Status in OpenStack Compute (nova):
  Incomplete
Status in os-brick:
  Fix Released

Bug description:
  OS-Brick on 1.14 and 1.15 returns real paths instead of returning
  symbolic links, which results in the encryption attach_volume call
  replacing the real device with a link to the crypt dm.

  The issue comes from the Nova flow when attaching an encrypted volume:

  1- Attach volume
  2- Generate libvirt configuration with path from step 1
  3- Encrypt attach volume

  Since step 2 has already generated the config with the path from step
  1 then step 3 must preserve this path.

  When step 1 returns a symbolic link we just forcefully replace it with
  a link to the crypt dm and everything is OK, but when we return a real
  path it does the same thing, which means we'll be replacing for
  example /dev/sda with a symlink, which will then break the detach
  process, and all future attachments.

  If flow order was changed to be 1, 3, 2 then the encrypt attach volume
  could give a different path to be used for the libvirt config
  generation.

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