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 <[email protected]> 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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
