yahoo-eng-team team mailing list archive

[Gorka Eguileor <geguileo@xxxxxxxxxx>]

Public bug reported:

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.

** Affects: cinder
     Importance: Undecided
         Status: New

** Affects: nova
     Importance: Undecided
         Status: New

** Affects: os-brick
     Importance: Undecided
         Status: New

** Also affects: cinder
   Importance: Undecided
       Status: New

** Also affects: nova
   Importance: Undecided
       Status: New

** Description changed:

  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.
+ 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.

-- 
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:
  New
Status in OpenStack Compute (nova):
  New
Status in os-brick:
  New

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