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.
Reviewed: https:/ /review. openstack. org/528694 /git.openstack. org/cgit/ openstack/ cinder/ commit/ ?id=3b01eb78ce1 c1ce388521f8122 b3d6b8f2686fda
Committed: https:/
Submitter: Zuul
Branch: master
commit 3b01eb78ce1c1ce 388521f8122b3d6 b8f2686fda
Author: Gorka Eguileor <email address hidden>
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 connection" method instead,
method creating the volume from an image doesn't use the method of that
class and calls the driver's "initialize_
which is missing the "encrypted" field.
Closes-Bug: #1703954 3f2ab16694c9787 c908251a382
Change-Id: I35db18f36f8668