[Bug 1822129] Re: [SRU] leave device name empty so that nova can determine it instead

Eric Desrochers eric.desrochers at canonical.com
Mon Apr 1 17:02:44 UTC 2019


** Description changed:

  [IMPACT]
  
  Horizon hardcoded 'vda' no matter what (legacy code) for boot volume
  scenarios. Meaning that if for instance we use an image with scsi
  decoration[1] horizon will name the device_name as 'vda' when it should
  be 'sda'.
  
  Inside the instance, it will be 'sda' but horizon will show 'vda', if
  you then attach a second volume the volume will be seen as 'sda' in
  horizon, but 'sdb' in the instance and so on ... creating a
  inconsistency, and can also cause in certain circumstance VM to have
  issue to successfully reboot, hanging with "No bootable device".
  
  There is 2 functions (thus fixes) separated as follow:
  
  * setFinalSpecBootImageToVolume() which already uses BDMv2, in this case it was just a matter to remove the 'device_name' attribute as suggested per documentation[2]. This function take care of boot image from volume scenario.
  -> https://review.openstack.org/#/c/644982/
  
  * setFinalSpecBootFromVolumeDevice() which currently uses BDMv1 (legacy), in this case an upgrade to BDMv2 without setting up a 'device_name' attribute is sufficient to fix the issue. This function take care of booting from existing volume and snapshot.
  -> https://review.openstack.org/648328/
  
  Basically, with theses 2 fixes, it is no longer relying on
  "vol_device_name= 'vda'" as it was before as it is no longer needed
  since Liberty (again as per documentation)
  
  An instance with scsi decoration will properly show 'sda' and without
  will show 'vda'.'vda' will still be taken when it's the right thing to
  do, but not because it is hardcorded like it used to before these fixes.
  
  [1] -  scsi meta decoration:
  hw_disk_bus='scsi'
  hw_scsi_model='virtio-scsi'
  
  [2]- https://docs.openstack.org/nova/stein/user/block-device-mapping
  
  [TEST CASE]
  
  Here's some use case I can think of ....
  
  With fix 1 in setFinalSpecBootImageToVolume():
  
  * Test #1:
  Use scsi meta data image decoration:
  hw_disk_bus='scsi'
  hw_scsi_model='virtio-scsi'
  
  1. Go to the Horizon dashboard and launch an instance
  2. Select "Boot from image (creates a new volume)" as Instance Boot Source
  
  Expected result:
  Instance should starts with /dev/sda as root device, instead of 'dev/vda'
  
  * Test #2:
  Use no scsi meta data image decoration
  
  1. Go to the Horizon dashboard and launch an instance
  2. Select "Boot from image (creates a new volume)" as Instance Boot Source
  
  Expected result:
  Instance will remain with /dev/vda as root device.
  No behaviour change here.
  
  With fix 2 in setFinalSpecBootFromVolumeDevice():
  
  * Test #1:
  Creating a server using an existing volume or volume snapshot.
  
  [POTENTIAL REGRESSION]
  
  * none expected, we basically leave nova to determine the device_name
  instead of having it force for Horizon by removing the 'device_name'
  attribute, and we also take benefit of it to upgrade some part of the
  code from legacy BDMv1 in flavor of BDMv2.
  
  * Note: This will not fix device name inconsistency already created
  instance, but will fix newly created instance after having applied the
  package from where these fixes have been first introduced.
  
  * Both fixes aren't dependant and can be SRU'd separately.
  
  [OTHER INFORMATION]
  
  * Upstream bug:
  https://bugs.launchpad.net/nova/+bug/1560965
  
  * Upstream git-review:
  
  # Taking care of bootimagefromvolume
  https://review.openstack.org/644982/
  https://github.com/openstack/horizon/commit/4788c4d2f59b8aa08e5f599a6d2c327b6004dc0c
  
  # Taking care of existing volume and snapshot
  https://review.openstack.org/648328/
+ 
+ * Upstream Cherry Pick request:
+ https://review.openstack.org/#/q/I9d114c2c2e6736a8f1a8092afa568f930b656f0

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/1822129

Title:
  [SRU] leave device name empty so that nova can determine it instead

Status in Ubuntu Cloud Archive:
  New
Status in Ubuntu Cloud Archive pike series:
  New
Status in Ubuntu Cloud Archive queens series:
  New
Status in Ubuntu Cloud Archive rocky series:
  New
Status in Ubuntu Cloud Archive stein series:
  New
Status in horizon package in Ubuntu:
  In Progress
Status in horizon source package in Bionic:
  New
Status in horizon source package in Cosmic:
  New
Status in horizon source package in Disco:
  In Progress

Bug description:
  [IMPACT]

  Horizon hardcoded 'vda' no matter what (legacy code) for boot volume
  scenarios. Meaning that if for instance we use an image with scsi
  decoration[1] horizon will name the device_name as 'vda' when it
  should be 'sda'.

  Inside the instance, it will be 'sda' but horizon will show 'vda', if
  you then attach a second volume the volume will be seen as 'sda' in
  horizon, but 'sdb' in the instance and so on ... creating a
  inconsistency, and can also cause in certain circumstance VM to have
  issue to successfully reboot, hanging with "No bootable device".

  There is 2 functions (thus fixes) separated as follow:

  * setFinalSpecBootImageToVolume() which already uses BDMv2, in this case it was just a matter to remove the 'device_name' attribute as suggested per documentation[2]. This function take care of boot image from volume scenario.
  -> https://review.openstack.org/#/c/644982/

  * setFinalSpecBootFromVolumeDevice() which currently uses BDMv1 (legacy), in this case an upgrade to BDMv2 without setting up a 'device_name' attribute is sufficient to fix the issue. This function take care of booting from existing volume and snapshot.
  -> https://review.openstack.org/648328/

  Basically, with theses 2 fixes, it is no longer relying on
  "vol_device_name= 'vda'" as it was before as it is no longer needed
  since Liberty (again as per documentation)

  An instance with scsi decoration will properly show 'sda' and without
  will show 'vda'.'vda' will still be taken when it's the right thing to
  do, but not because it is hardcorded like it used to before these
  fixes.

  [1] -  scsi meta decoration:
  hw_disk_bus='scsi'
  hw_scsi_model='virtio-scsi'

  [2]- https://docs.openstack.org/nova/stein/user/block-device-mapping

  [TEST CASE]

  Here's some use case I can think of ....

  With fix 1 in setFinalSpecBootImageToVolume():

  * Test #1:
  Use scsi meta data image decoration:
  hw_disk_bus='scsi'
  hw_scsi_model='virtio-scsi'

  1. Go to the Horizon dashboard and launch an instance
  2. Select "Boot from image (creates a new volume)" as Instance Boot Source

  Expected result:
  Instance should starts with /dev/sda as root device, instead of 'dev/vda'

  * Test #2:
  Use no scsi meta data image decoration

  1. Go to the Horizon dashboard and launch an instance
  2. Select "Boot from image (creates a new volume)" as Instance Boot Source

  Expected result:
  Instance will remain with /dev/vda as root device.
  No behaviour change here.

  With fix 2 in setFinalSpecBootFromVolumeDevice():

  * Test #1:
  Creating a server using an existing volume or volume snapshot.

  [POTENTIAL REGRESSION]

  * none expected, we basically leave nova to determine the device_name
  instead of having it force for Horizon by removing the 'device_name'
  attribute, and we also take benefit of it to upgrade some part of the
  code from legacy BDMv1 in flavor of BDMv2.

  * Note: This will not fix device name inconsistency already created
  instance, but will fix newly created instance after having applied the
  package from where these fixes have been first introduced.

  * Both fixes aren't dependant and can be SRU'd separately.

  [OTHER INFORMATION]

  * Upstream bug:
  https://bugs.launchpad.net/nova/+bug/1560965

  * Upstream git-review:

  # Taking care of bootimagefromvolume
  https://review.openstack.org/644982/
  https://github.com/openstack/horizon/commit/4788c4d2f59b8aa08e5f599a6d2c327b6004dc0c

  # Taking care of existing volume and snapshot
  https://review.openstack.org/648328/

  * Upstream Cherry Pick request:
  https://review.openstack.org/#/q/I9d114c2c2e6736a8f1a8092afa568f930b656f0

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1822129/+subscriptions



More information about the Ubuntu-openstack-bugs mailing list