| 2019-03-28 15:24:58 |
Eric Desrochers |
bug |
|
|
added bug |
| 2019-03-28 15:25:21 |
Eric Desrochers |
tags |
|
sts |
|
| 2019-03-28 15:27:09 |
Eric Desrochers |
horizon (Ubuntu): assignee |
|
Eric Desrochers (slashd) |
|
| 2019-03-28 15:27:11 |
Eric Desrochers |
horizon (Ubuntu): importance |
Undecided |
Medium |
|
| 2019-03-28 15:27:15 |
Eric Desrochers |
horizon (Ubuntu): status |
New |
In Progress |
|
| 2019-03-28 15:28:12 |
Eric Desrochers |
description |
Upstream bug:
https://bugs.launchpad.net/nova/+bug/1560965
Upstream git-review:
[git-review] https://review.openstack.org/644982/ # Taking care of bootimagefromvolume
[git-review] https://review.openstack.org/648328/ # Taking care of existing volume and snapshot
Description:
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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.html |
Upstream bug:
https://bugs.launchpad.net/nova/+bug/1560965
Upstream git-review:
[git-review] https://review.openstack.org/644982/ # Taking care of bootimagefromvolume
[git-review] https://review.openstack.org/648328/ # Taking care of existing volume and snapshot
Description:
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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.html |
|
| 2019-03-28 15:28:55 |
Eric Desrochers |
description |
Upstream bug:
https://bugs.launchpad.net/nova/+bug/1560965
Upstream git-review:
[git-review] https://review.openstack.org/644982/ # Taking care of bootimagefromvolume
[git-review] https://review.openstack.org/648328/ # Taking care of existing volume and snapshot
Description:
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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.html |
* Upstream bug:
https://bugs.launchpad.net/nova/+bug/1560965
* Upstream git-review:
# Taking care of bootimagefromvolume
https://review.openstack.org/644982/
# Taking care of existing volume and snapshot
https://review.openstack.org/648328/
* Description:
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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 |
|
| 2019-03-28 15:35:58 |
Eric Desrochers |
description |
* Upstream bug:
https://bugs.launchpad.net/nova/+bug/1560965
* Upstream git-review:
# Taking care of bootimagefromvolume
https://review.openstack.org/644982/
# Taking care of existing volume and snapshot
https://review.openstack.org/648328/
* Description:
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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 |
[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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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]
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
Boot from : Volume snapshot and Volume also will implicitly pick '/dev/vda'
[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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
[OTHER INFORMATION]
* Upstream bug:
https://bugs.launchpad.net/nova/+bug/1560965
* Upstream git-review:
# Taking care of bootimagefromvolume
https://review.openstack.org/644982/
# Taking care of existing volume and snapshot
https://review.openstack.org/648328/ |
|
| 2019-03-28 15:36:42 |
Eric Desrochers |
nominated for series |
|
Ubuntu Disco |
|
| 2019-03-28 15:36:42 |
Eric Desrochers |
bug task added |
|
horizon (Ubuntu Disco) |
|
| 2019-03-28 15:36:42 |
Eric Desrochers |
nominated for series |
|
Ubuntu Cosmic |
|
| 2019-03-28 15:36:42 |
Eric Desrochers |
bug task added |
|
horizon (Ubuntu Cosmic) |
|
| 2019-03-28 15:36:42 |
Eric Desrochers |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-03-28 15:36:42 |
Eric Desrochers |
bug task added |
|
horizon (Ubuntu Xenial) |
|
| 2019-03-28 15:36:42 |
Eric Desrochers |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-03-28 15:36:42 |
Eric Desrochers |
bug task added |
|
horizon (Ubuntu Bionic) |
|
| 2019-03-28 15:38:38 |
Eric Desrochers |
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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]
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
Boot from : Volume snapshot and Volume also will implicitly pick '/dev/vda'
[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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
[OTHER INFORMATION]
* Upstream bug:
https://bugs.launchpad.net/nova/+bug/1560965
* Upstream git-review:
# Taking care of bootimagefromvolume
https://review.openstack.org/644982/
# Taking care of existing volume and snapshot
https://review.openstack.org/648328/ |
[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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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]
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
Boot from : Volume snapshot and Volume also will implicitly pick '/dev/vda'
[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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fix has been first introduced.
[OTHER INFORMATION]
* Upstream bug:
https://bugs.launchpad.net/nova/+bug/1560965
* Upstream git-review:
# Taking care of bootimagefromvolume
https://review.openstack.org/644982/
# Taking care of existing volume and snapshot
https://review.openstack.org/648328/ |
|
| 2019-03-28 15:51:49 |
Eric Desrochers |
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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]
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
Boot from : Volume snapshot and Volume also will implicitly pick '/dev/vda'
[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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fix has been first introduced.
[OTHER INFORMATION]
* Upstream bug:
https://bugs.launchpad.net/nova/+bug/1560965
* Upstream git-review:
# Taking care of bootimagefromvolume
https://review.openstack.org/644982/
# Taking care of existing volume and snapshot
https://review.openstack.org/648328/ |
[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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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]
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
Boot from : Volume snapshot and Volume also will implicitly pick '/dev/vda'
[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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced.
[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/ |
|
| 2019-03-28 15:52:32 |
Eric Desrochers |
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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]
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
Boot from : Volume snapshot and Volume also will implicitly pick '/dev/vda'
[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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced.
[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/ |
[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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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]
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
This above also applies to boot from exiting volume and 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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced.
[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/ |
|
| 2019-03-28 16:00:56 |
Eric Desrochers |
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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]
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
This above also applies to boot from exiting volume and 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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced.
[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/ |
[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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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 ....
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
This above also applies to boot from exiting volume and 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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced.
[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/ |
|
| 2019-03-28 16:01:49 |
Eric Desrochers |
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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 ....
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
This above also applies to boot from exiting volume and 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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced.
[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/ |
[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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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 ....
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
This above also applies to boot from existing volume and 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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced.
[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/ |
|
| 2019-03-28 16:08:06 |
Eric Desrochers |
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, creating a inconsistency depending from where you look at, and can also cause VM to have issue to successfully reboot, hanging with "No bootable device".
There is 2 functions separate 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.
* 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.
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 ....
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
This above also applies to boot from existing volume and 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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced.
[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/ |
[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 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.
* 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.
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 ....
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
This above also applies to boot from existing volume and 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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced.
[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/ |
|
| 2019-03-28 16:08:30 |
Eric Desrochers |
summary |
leave device name empty so that nova can determine it instead |
[SRU] leave device name empty so that nova can determine it instead |
|
| 2019-03-28 20:04:04 |
Eric Desrochers |
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 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.
* 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.
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 ....
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
This above also applies to boot from existing volume and 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 promote some part of the code from legacy BDMv1 to BDMv2. This will fix the inconsistency that annoy Horizon users for quite some time now.
* Note: This will not fix already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced.
[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/ |
[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 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.
* 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.
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 ....
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
This above also applies to boot from existing volume and 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.
[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/ |
|
| 2019-04-01 12:58:51 |
Corey Bryant |
bug task deleted |
horizon (Ubuntu Xenial) |
|
|
| 2019-04-01 12:59:03 |
Corey Bryant |
bug task added |
|
cloud-archive |
|
| 2019-04-01 12:59:16 |
Corey Bryant |
nominated for series |
|
cloud-archive/pike |
|
| 2019-04-01 12:59:16 |
Corey Bryant |
bug task added |
|
cloud-archive/pike |
|
| 2019-04-01 12:59:16 |
Corey Bryant |
nominated for series |
|
cloud-archive/stein |
|
| 2019-04-01 12:59:16 |
Corey Bryant |
bug task added |
|
cloud-archive/stein |
|
| 2019-04-01 12:59:16 |
Corey Bryant |
nominated for series |
|
cloud-archive/rocky |
|
| 2019-04-01 12:59:16 |
Corey Bryant |
bug task added |
|
cloud-archive/rocky |
|
| 2019-04-01 12:59:16 |
Corey Bryant |
nominated for series |
|
cloud-archive/queens |
|
| 2019-04-01 12:59:16 |
Corey Bryant |
bug task added |
|
cloud-archive/queens |
|
| 2019-04-01 13:34:50 |
Eric Desrochers |
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 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.
* 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.
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 ....
* Test #1 :
Use Xen as hypervisor
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/xvda as root device, instead of 'dev/vda'
* Test #2:
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 #3:
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.
* Test #4:
This above also applies to boot from existing volume and 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.
[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/ |
[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 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.
* 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.
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 ....
* 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 #3:
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.
* Test #3:
This above also applies to boot from existing volume and 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.
[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/ |
|
| 2019-04-01 13:35:21 |
Eric Desrochers |
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 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.
* 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.
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 ....
* 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 #3:
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.
* Test #3:
This above also applies to boot from existing volume and 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.
[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/ |
[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 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.
* 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.
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 ....
* 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.
* Test #3:
This above also applies to boot from existing volume and 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.
[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/ |
|
| 2019-04-01 15:22:46 |
Eric Desrochers |
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 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.
* 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.
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 ....
* 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.
* Test #3:
This above also applies to boot from existing volume and 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.
[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/ |
[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 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.
* 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.
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/ |
|
| 2019-04-01 15:36:29 |
Eric Desrochers |
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 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.
* 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.
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/ |
[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/ |
|
| 2019-04-01 15:47:23 |
Eric Desrochers |
attachment added |
|
lp1822129-disco.debdiff https://bugs.launchpad.net/ubuntu/+source/horizon/+bug/1822129/+attachment/5251737/+files/lp1822129-disco.debdiff |
|
| 2019-04-01 15:51:41 |
Eric Desrochers |
attachment removed |
lp1822129-disco.debdiff https://bugs.launchpad.net/ubuntu/+source/horizon/+bug/1822129/+attachment/5251737/+files/lp1822129-disco.debdiff |
|
|
| 2019-04-01 15:53:35 |
Eric Desrochers |
attachment added |
|
lp1822129-disco.debdiff https://bugs.launchpad.net/ubuntu/+source/horizon/+bug/1822129/+attachment/5251739/+files/lp1822129-disco.debdiff |
|
| 2019-04-01 16:21:40 |
Ubuntu Foundations Team Bug Bot |
tags |
sts |
patch sts |
|
| 2019-04-01 17:02:44 |
Eric Desrochers |
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/ |
[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 |
|
| 2019-04-01 17:08:56 |
Eric Desrochers |
merge proposal linked |
|
https://code.launchpad.net/~slashd/ubuntu/+source/horizon/+git/horizon/+merge/365364 |
|
| 2019-04-01 17:18:05 |
Eric Desrochers |
cloud-archive/stein: assignee |
|
Eric Desrochers (slashd) |
|
| 2019-04-01 17:18:08 |
Eric Desrochers |
cloud-archive/stein: status |
New |
In Progress |
|
| 2019-04-02 13:44:08 |
Launchpad Janitor |
horizon (Ubuntu Disco): status |
In Progress |
Fix Released |
|
| 2019-04-02 16:16:14 |
Eric Desrochers |
horizon (Ubuntu Cosmic): status |
New |
In Progress |
|
| 2019-04-02 16:16:15 |
Eric Desrochers |
horizon (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-04-02 16:16:18 |
Eric Desrochers |
horizon (Ubuntu Cosmic): assignee |
|
Eric Desrochers (slashd) |
|
| 2019-04-02 16:16:19 |
Eric Desrochers |
horizon (Ubuntu Bionic): assignee |
|
Eric Desrochers (slashd) |
|
| 2019-04-02 16:16:22 |
Eric Desrochers |
horizon (Ubuntu Cosmic): importance |
Undecided |
Medium |
|
| 2019-04-02 16:16:24 |
Eric Desrochers |
horizon (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2019-04-02 16:16:33 |
Eric Desrochers |
cloud-archive/rocky: assignee |
|
Eric Desrochers (slashd) |
|
| 2019-04-02 16:16:35 |
Eric Desrochers |
cloud-archive/queens: assignee |
|
Eric Desrochers (slashd) |
|
| 2019-04-02 16:16:37 |
Eric Desrochers |
cloud-archive/pike: assignee |
|
Eric Desrochers (slashd) |
|
| 2019-04-02 16:16:47 |
Eric Desrochers |
cloud-archive/stein: status |
In Progress |
Confirmed |
|
| 2019-04-02 16:16:49 |
Eric Desrochers |
cloud-archive/rocky: status |
New |
Confirmed |
|
| 2019-04-02 16:16:50 |
Eric Desrochers |
cloud-archive/queens: status |
New |
Confirmed |
|
| 2019-04-02 16:16:52 |
Eric Desrochers |
cloud-archive/pike: status |
New |
Confirmed |
|
| 2019-04-16 13:55:53 |
Eric Desrochers |
merge proposal linked |
|
https://code.launchpad.net/~slashd/ubuntu/+source/horizon/+git/horizon/+merge/366119 |
|
| 2019-04-16 14:22:50 |
Eric Desrochers |
attachment added |
|
lp1822129-cosmic.debdiff https://bugs.launchpad.net/ubuntu/bionic/+source/horizon/+bug/1822129/+attachment/5256277/+files/lp1822129-cosmic.debdiff |
|
| 2019-04-16 14:27:53 |
Eric Desrochers |
attachment added |
|
lp1822129-bionic.debdiff https://bugs.launchpad.net/ubuntu/bionic/+source/horizon/+bug/1822129/+attachment/5256278/+files/lp1822129-bionic.debdiff |
|
| 2019-04-16 14:41:44 |
Eric Desrochers |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-04-16 14:41:44 |
Eric Desrochers |
bug task added |
|
horizon (Ubuntu Xenial) |
|
| 2019-04-16 14:41:59 |
Eric Desrochers |
horizon (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2019-04-16 14:41:59 |
Eric Desrochers |
horizon (Ubuntu Xenial): status |
New |
In Progress |
|
| 2019-04-16 14:41:59 |
Eric Desrochers |
horizon (Ubuntu Xenial): assignee |
|
Eric Desrochers (slashd) |
|
| 2019-04-16 14:53:30 |
Eric Desrochers |
attachment added |
|
lp1822129-xenial.debdiff https://bugs.launchpad.net/ubuntu/xenial/+source/horizon/+bug/1822129/+attachment/5256281/+files/lp1822129-xenial.debdiff |
|
| 2019-05-07 15:43:48 |
Corey Bryant |
cloud-archive/stein: status |
Confirmed |
Fix Released |
|
| 2019-05-07 15:46:12 |
Corey Bryant |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-05-07 15:46:22 |
Corey Bryant |
cloud-archive/rocky: importance |
Undecided |
Medium |
|
| 2019-05-07 15:46:22 |
Corey Bryant |
cloud-archive/rocky: status |
Confirmed |
Triaged |
|
| 2019-05-07 15:46:35 |
Corey Bryant |
cloud-archive/queens: importance |
Undecided |
Medium |
|
| 2019-05-07 15:46:35 |
Corey Bryant |
cloud-archive/queens: status |
Confirmed |
Triaged |
|
| 2019-05-07 15:46:46 |
Corey Bryant |
cloud-archive/pike: importance |
Undecided |
Medium |
|
| 2019-05-07 15:46:46 |
Corey Bryant |
cloud-archive/pike: status |
Confirmed |
Triaged |
|
| 2019-05-09 12:59:14 |
Corey Bryant |
cloud-archive/pike: status |
Triaged |
Fix Committed |
|
| 2019-05-09 12:59:16 |
Corey Bryant |
tags |
patch sts |
patch sts verification-pike-needed |
|
| 2019-05-09 17:24:33 |
Eric Desrochers |
tags |
patch sts verification-pike-needed |
patch sts verification-pike-done |
|
| 2019-05-09 17:33:42 |
Eric Desrochers |
tags |
patch sts verification-pike-done |
patch sts verification-done-pike verification-pike-done |
|
| 2019-05-14 22:04:09 |
Brian Murray |
horizon (Ubuntu Cosmic): status |
In Progress |
Fix Committed |
|
| 2019-05-14 22:04:13 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2019-05-14 22:04:18 |
Brian Murray |
tags |
patch sts verification-done-pike verification-pike-done |
patch sts verification-done-pike verification-needed verification-needed-cosmic verification-pike-done |
|
| 2019-05-14 22:06:44 |
Brian Murray |
horizon (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-05-14 22:06:49 |
Brian Murray |
tags |
patch sts verification-done-pike verification-needed verification-needed-cosmic verification-pike-done |
patch sts verification-done-pike verification-needed verification-needed-bionic verification-needed-cosmic verification-pike-done |
|
| 2019-05-15 14:25:12 |
Corey Bryant |
cloud-archive/rocky: status |
Triaged |
Fix Committed |
|
| 2019-05-15 14:25:14 |
Corey Bryant |
tags |
patch sts verification-done-pike verification-needed verification-needed-bionic verification-needed-cosmic verification-pike-done |
patch sts verification-done-pike verification-needed verification-needed-bionic verification-needed-cosmic verification-pike-done verification-rocky-needed |
|
| 2019-05-15 14:27:46 |
Corey Bryant |
cloud-archive/queens: status |
Triaged |
Fix Committed |
|
| 2019-05-15 14:27:54 |
Corey Bryant |
tags |
patch sts verification-done-pike verification-needed verification-needed-bionic verification-needed-cosmic verification-pike-done verification-rocky-needed |
patch sts verification-done-pike verification-needed verification-needed-bionic verification-needed-cosmic verification-pike-done verification-queens-needed verification-rocky-needed |
|
| 2019-05-15 15:33:29 |
Eric Desrochers |
tags |
patch sts verification-done-pike verification-needed verification-needed-bionic verification-needed-cosmic verification-pike-done verification-queens-needed verification-rocky-needed |
patch sts verification-done-bionic verification-done-pike verification-needed verification-needed-cosmic verification-pike-done verification-queens-needed verification-rocky-needed |
|
| 2019-05-15 15:37:42 |
Eric Desrochers |
tags |
patch sts verification-done-bionic verification-done-pike verification-needed verification-needed-cosmic verification-pike-done verification-queens-needed verification-rocky-needed |
patch sts verification-done-bionic verification-done-pike verification-needed verification-needed-cosmic verification-pike-done verification-queens-done verification-rocky-needed |
|
| 2019-05-16 01:09:29 |
Eric Desrochers |
tags |
patch sts verification-done-bionic verification-done-pike verification-needed verification-needed-cosmic verification-pike-done verification-queens-done verification-rocky-needed |
patch sts verification-done-bionic verification-done-cosmic verification-done-pike verification-needed verification-pike-done verification-queens-done verification-rocky-done |
|
| 2019-05-30 08:31:44 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-05-30 08:41:41 |
Launchpad Janitor |
horizon (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2019-05-30 08:45:48 |
Launchpad Janitor |
horizon (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-05-30 13:27:17 |
Corey Bryant |
cloud-archive/rocky: status |
Fix Committed |
Fix Released |
|
| 2019-05-30 13:28:20 |
Corey Bryant |
cloud-archive/queens: status |
Fix Committed |
Fix Released |
|
| 2019-05-30 13:29:45 |
Corey Bryant |
cloud-archive/pike: status |
Fix Committed |
Fix Released |
|
| 2019-06-10 20:46:25 |
Eric Desrochers |
horizon (Ubuntu Xenial): assignee |
Eric Desrochers (slashd) |
|
|
