Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-04-29
16:14:39 gibi sean-k-mooney: lol, I totally forgot
16:14:39 gibi sean-k-mooney: lol, I totally forgot
16:15:02 gibi thanks again
16:15:02 gibi thanks again
16:26:31 elod lyarwood: I've checked the placement patch meanwhile and +2+W'd as it looks appropriate
16:26:31 elod lyarwood: I've checked the placement patch meanwhile and +2+W'd as it looks appropriate
16:26:52 lyarwood ack thanks
16:26:52 gmann elod: lyarwood its base patch too -https://review.opendev.org/c/openstack/placement/+/787525/2
16:26:52 lyarwood ack thanks
16:26:52 gmann elod: lyarwood its base patch too -https://review.opendev.org/c/openstack/placement/+/787525/2
16:29:35 gibi and if you are reviewing placement already could you please hit this too https://review.opendev.org/c/openstack/placement/+/787508 ?
16:29:35 gibi and if you are reviewing placement already could you please hit this too https://review.opendev.org/c/openstack/placement/+/787508 ?
16:29:43 gibi simple job addition
16:29:43 gibi simple job addition
16:29:51 elod gmann: +2+W'd, too
16:29:51 elod gmann: +2+W'd, too
16:31:17 gmann elod: thanks
16:31:17 gmann elod: thanks
16:31:45 elod np
16:31:45 elod np
16:33:11 gmann gibi: lgtm, +A
16:33:11 gmann gibi: lgtm, +A
16:34:10 gmann gibi: sean-k-mooney that is good idea. I will try this for few of QA repos too where we do not have frequent changes and end up finding failing gate if there is any change.
16:34:10 gmann gibi: sean-k-mooney that is good idea. I will try this for few of QA repos too where we do not have frequent changes and end up finding failing gate if there is any change.
16:37:39 sean-k-mooney gmann: the weekly pipeline give a nice cadence to them too
16:37:39 sean-k-mooney gmann: the weekly pipeline give a nice cadence to them too
16:38:22 kashyap lyarwood: Hey
16:38:22 kashyap lyarwood: Hey
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: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

Earlier   Later