| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-29 | |||
| 16:38:32 | sean-k-mooney | being realistinc peopel are not going to check them daily and if its a 2 second line item in the weekly meeting just to make sure the last build ran and it was green then i think its useful | |
| 16:38:52 | kashyap | lyarwood: We don't use "virtio-blk,scsi=on" as a SCSI passthrough, right? From my `grep`ing around, we don't... | |
| 16:38:52 | kashyap | lyarwood: We don't use "virtio-blk,scsi=on" as a SCSI passthrough, right? From my `grep`ing around, we don't... | |
| 16:39:13 | kashyap | lyarwood: I ask because, QEMU folks pinged me to tell that support for it was removed in Linux v5.6; and QEMU deprecated it in 5.0 | |
| 16:39:14 | kashyap | lyarwood: I ask because, QEMU folks pinged me to tell that support for it was removed in Linux v5.6; and QEMU deprecated it in 5.0 | |
| 16:39:29 | gmann | sean-k-mooney: true, we check periodic jobs in QA office hours weekly and it will hell to add these type of jobs in less-active repo | |
| 16:39:29 | gmann | sean-k-mooney: true, we check periodic jobs in QA office hours weekly and it will hell to add these type of jobs in less-active repo | |
| 16:39:40 | sean-k-mooney | kashyap: i dont belive we do | |
| 16:39:40 | sean-k-mooney | kashyap: i dont belive we do | |
| 16:39:53 | kashyap | Cool; figured as much | |
| 16:39:53 | kashyap | Cool; figured as much | |
| 16:41:41 | sean-k-mooney | gmann: i have tought about doing it for os-vif in the past but i tened to test that trasitivly enough in my local devstack but its useful in any repo that does not ahve a patch proplsed at least once a week | |
| 16:41:42 | sean-k-mooney | gmann: i have tought about doing it for os-vif in the past but i tened to test that trasitivly enough in my local devstack but its useful in any repo that does not ahve a patch proplsed at least once a week | |
| 16:43:01 | gmann | +1, what i encounter is trying to add some change but see gate is already failing for long and we did not knw about it and end up spending time on that in release time or so :) | |
| 16:43:01 | gmann | +1, what i encounter is trying to add some change but see gate is already failing for long and we did not knw about it and end up spending time on that in release time or so :) | |
| 16:47:32 | BLZbubba | hi guys, when i create a uefi image with openstack image create and specify "os_secure_boot=disabled", this property is ignored and nova forces the uefi secboot bios instead. interestingly it is only ignored when I also specify "hw_firmware_type=uefi" so it must be happening at a higher level than just glance.... any idea how to stop nova from trying the secboot version of ovmf? | |
| 16:47:32 | BLZbubba | hi guys, when i create a uefi image with openstack image create and specify "os_secure_boot=disabled", this property is ignored and nova forces the uefi secboot bios instead. interestingly it is only ignored when I also specify "hw_firmware_type=uefi" so it must be happening at a higher level than just glance.... any idea how to stop nova from trying the secboot version of ovmf? | |
| 16:48:49 | BLZbubba | apart from the gross hack I've been using, which is rm /usr/share/OVMF/OVMF_CODE.secboot.fd | |
| 16:48:49 | BLZbubba | apart from the gross hack I've been using, which is rm /usr/share/OVMF/OVMF_CODE.secboot.fd | |
| 16:49:28 | BLZbubba | the glance people said to ask here | |
| 16:49:28 | BLZbubba | the glance people said to ask here | |
| 16:58:27 | sean-k-mooney | BLZbubba: so secure boot shoudl be disabled by default | |
| 16:58:27 | sean-k-mooney | BLZbubba: so secure boot shoudl be disabled by default | |
| 16:58:55 | sean-k-mooney | if you jsut set hw_firmware_type=uefi it should use the non secure boot firmware | |
| 16:58:55 | sean-k-mooney | if you jsut set hw_firmware_type=uefi it should use the non secure boot firmware | |
| 16:59:29 | sean-k-mooney | unless the recnelty added secure boot support feature regressed that behavior | |
| 16:59:29 | sean-k-mooney | unless the recnelty added secure boot support feature regressed that behavior | |
| 16:59:36 | sean-k-mooney | stephenfin: kashyap ^ | |
| 16:59:36 | sean-k-mooney | stephenfin: kashyap ^ | |
| 17:00:32 | stephenfin | BLZbubba: what version of nova? | |
| 17:00:32 | stephenfin | BLZbubba: what version of nova? | |
| 17:02:16 | stephenfin | sean-k-mooney: Prior to the secure boot feature, we defaulted the secure boot firmware https://github.com/openstack/nova/commit/363710b655434a15b6b85d9ca65343210b104e56 | |
| 17:02:17 | stephenfin | sean-k-mooney: Prior to the secure boot feature, we defaulted the secure boot firmware https://github.com/openstack/nova/commit/363710b655434a15b6b85d9ca65343210b104e56 | |
| 17:02:44 | sean-k-mooney | stephenfin: but we did not enable secureboot in the xml so it was disabled in the geust | |
| 17:02:45 | sean-k-mooney | stephenfin: but we did not enable secureboot in the xml so it was disabled in the geust | |
| 17:02:46 | stephenfin | though we didn't set the necessary flags, so it should be using the firmware but not enabling the feature | |
| 17:02:46 | stephenfin | though we didn't set the necessary flags, so it should be using the firmware but not enabling the feature | |
| 17:02:50 | stephenfin | yes | |
| 17:03:11 | sean-k-mooney | so the firmwar was capable fo secure boot but qemu woudl not try to use it | |
| 17:03:11 | sean-k-mooney | so the firmwar was capable fo secure boot but qemu woudl not try to use it | |
| 17:03:17 | sean-k-mooney | so we should still have the same behavior | |
| 17:03:17 | sean-k-mooney | so we should still have the same behavior | |
| 17:03:35 | stephenfin | yes | |
| 17:03:58 | sean-k-mooney | BLZbubba: is this breaking you some how? | |
| 17:03:58 | sean-k-mooney | BLZbubba: is this breaking you some how? | |
| 17:04:51 | sean-k-mooney | BLZbubba: os_secure_boot prior to the wallaby relesae was only suppoted by hyperv | |
| 17:04:51 | sean-k-mooney | BLZbubba: os_secure_boot prior to the wallaby relesae was only suppoted by hyperv | |
| 17:05:37 | BLZbubba | I'm using ubunbu lts: 2:21.1.2-0ubuntu1 | |
| 17:05:38 | BLZbubba | I'm using ubunbu lts: 2:21.1.2-0ubuntu1 | |
| 17:06:20 | sean-k-mooney | so ussuri | |
| 17:06:20 | sean-k-mooney | so ussuri | |
| 17:06:24 | BLZbubba | yes | |
| 17:06:24 | BLZbubba | yes | |
| 17:06:44 | sean-k-mooney | in that release the libvirt dirver does not support securebot or os_secure_boot | |
| 17:06:45 | sean-k-mooney | in that release the libvirt dirver does not support securebot or os_secure_boot | |
| 17:07:08 | sean-k-mooney | only the hyperv driver supported os_secure_boot at that time | |
| 17:07:08 | sean-k-mooney | only the hyperv driver supported os_secure_boot at that time | |
| 17:07:24 | sean-k-mooney | BLZbubba: your vms are not actlly using secure boot in this case | |
| 17:07:25 | sean-k-mooney | BLZbubba: your vms are not actlly using secure boot in this case | |
| 17:10:38 | BLZbubba | ok thanks for the info. I just know that if OVMF_CODE.secboot.fd is in the libvirt xml (which it is by default) they fail to boot. but it sounds like it should work... i'll play around with the qemu options and see if I can figure this out. | |
| 17:10:38 | BLZbubba | ok thanks for the info. I just know that if OVMF_CODE.secboot.fd is in the libvirt xml (which it is by default) they fail to boot. but it sounds like it should work... i'll play around with the qemu options and see if I can figure this out. | |
| 17:10:42 | BLZbubba | thanks! | |
| 17:10:42 | BLZbubba | thanks! | |
| 17:11:52 | sean-k-mooney | sound like there is a bug in the ovmf package that canonical is shiping in 20.04 | |
| 17:11:52 | sean-k-mooney | sound like there is a bug in the ovmf package that canonical is shiping in 20.04 | |
| 17:12:19 | sean-k-mooney | i think they recently rebased the version fo qemu they ship in the cloud archive | |
| 17:12:19 | sean-k-mooney | i think they recently rebased the version fo qemu they ship in the cloud archive | |
| 17:12:26 | sean-k-mooney | maybe that broke something | |
| 17:12:26 | sean-k-mooney | maybe that broke something | |
| 17:28:29 | erbarr | hello, what could be causing this, I stacked last night with FORCE_CONFIG_DRIVE on ussuri and ran into it. Didn't see it on other branches up to train https://usercontent.irccloud-cdn.com/file/p1kmwH0W/image.png | |
| 17:28:29 | erbarr | hello, what could be causing this, I stacked last night with FORCE_CONFIG_DRIVE on ussuri and ran into it. Didn't see it on other branches up to train https://usercontent.irccloud-cdn.com/file/p1kmwH0W/image.png | |
| 17:29:46 | sean-k-mooney | its a python 3 issue | |
| 17:29:46 | sean-k-mooney | its a python 3 issue | |
| 17:30:00 | sean-k-mooney | in this case i thik its cause by libguestfs | |
| 17:30:00 | sean-k-mooney | in this case i thik its cause by libguestfs | |
| 17:30:36 | sean-k-mooney | lyarwood: gibi ^ is that the libguestfs issue ye were seeing in the gate | |
| 17:30:37 | sean-k-mooney | lyarwood: gibi ^ is that the libguestfs issue ye were seeing in the gate | |
| 17:31:12 | lyarwood | that's ironic so I wouldn't think so | |
| 17:31:13 | lyarwood | that's ironic so I wouldn't think so | |
| 17:31:16 | lyarwood | and configdrive related | |
| 17:31:16 | lyarwood | and configdrive related | |
| 17:32:03 | sean-k-mooney | well maybe its form makeiso | |
| 17:32:03 | sean-k-mooney | well maybe its form makeiso | |
| 17:32:20 | openstackgerrit | Merged openstack/placement stable/wallaby: Add a reproduction test for bug story/2008831 https://review.opendev.org/c/openstack/placement/+/787525 | |
| 17:32:20 | openstackgerrit | Merged openstack/placement stable/wallaby: Add a reproduction test for bug story/2008831 https://review.opendev.org/c/openstack/placement/+/787525 | |
| 17:32:27 | sean-k-mooney | its the same bytes vs str issue | |
| 17:32:27 | sean-k-mooney | its the same bytes vs str issue | |
| 17:32:29 | lyarwood | hard to tell from that trace tbh | |
| 17:32:29 | lyarwood | hard to tell from that trace tbh | |
| 17:32:31 | lyarwood | yeah | |
| 17:32:37 | lyarwood | it's that underlying issue | |
| 17:32:37 | lyarwood | it's that underlying issue | |
| 17:34:27 | sean-k-mooney | so that being raised form here https://github.com/openstack/nova/blob/stable/ussuri/nova/virt/ironic/driver.py#L544-L548 | |
| 17:34:27 | sean-k-mooney | so that being raised form here https://github.com/openstack/nova/blob/stable/ussuri/nova/virt/ironic/driver.py#L544-L548 | |
| 17:34:44 | sean-k-mooney | but i feel like the excption is actully happening in ironic | |
| 17:34:45 | sean-k-mooney | but i feel like the excption is actully happening in ironic | |
| 17:35:19 | sean-k-mooney | and they are just propagating it up to us | |
| 17:35:19 | sean-k-mooney | and they are just propagating it up to us | |
| 17:35:40 | sean-k-mooney | erbarr: do you ahve any error in the ironic conductor for the deploy | |
| 17:35:40 | sean-k-mooney | erbarr: do you ahve any error in the ironic conductor for the deploy | |