Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-04-29
16:04:23 sean-k-mooney it shows how frequetly people use the network jsone templating if we are only seeing this now
16:04:23 sean-k-mooney it shows how frequetly people use the network jsone templating if we are only seeing this now
16:05:51 sean-k-mooney this is used to validate https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.injected_network_template right
16:05:52 sean-k-mooney this is used to validate https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.injected_network_template right
16:06:39 gibi sean-k-mooney: ooh, I did not know about that
16:06:39 gibi sean-k-mooney: ooh, I did not know about that
16:06:42 gibi but I guess yes
16:06:42 gibi but I guess yes
16:07:41 openstackgerrit Ghanshyam proposed openstack/nova master: DNM: testing bionic drop https://review.opendev.org/c/openstack/nova/+/788791
16:07:41 openstackgerrit Ghanshyam proposed openstack/nova master: DNM: testing bionic drop https://review.opendev.org/c/openstack/nova/+/788791
16:07:46 sean-k-mooney well im not sure what we might be using the network.json for other then the network metadta consumed by cloud init which i think is generated by that template
16:07:46 sean-k-mooney well im not sure what we might be using the network.json for other then the network metadta consumed by cloud init which i think is generated by that template
16:10:54 gibi it make sense
16:10:54 gibi it make sense
16:11:44 gibi btw sean-k-mooney you promised on the PTG to add periodic jobs for placement and then we can look at the results in regularly on the nova meeting
16:11:44 gibi btw sean-k-mooney you promised on the PTG to add periodic jobs for placement and then we can look at the results in regularly on the nova meeting
16:12:00 gibi let me know if you need help adding them
16:12:00 gibi let me know if you need help adding them
16:12:21 sean-k-mooney oh i should be in the meeting didn realise it started
16:12:22 sean-k-mooney oh i should be in the meeting didn realise it started
16:12:30 gibi :)
16:13:03 sean-k-mooney https://review.opendev.org/c/openstack/placement/+/787508
16:13:03 sean-k-mooney https://review.opendev.org/c/openstack/placement/+/787508
16:13:12 sean-k-mooney you looked at the patch already
16:13:13 sean-k-mooney you looked at the patch already
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

Earlier   Later