| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-07-24 | |||
| 11:00:21 | sean-k-mooney | mikal: so when addign flavor extra specs please make sure you add a vlaidator too | |
| 11:00:53 | sean-k-mooney | mikal: yes you have two options on that front. start a singel releasenote in the base patch that has a useable feature and update it in the rest | |
| 11:01:15 | sean-k-mooney | or have a sperate release note for each seperate adddtion of funcitonality | |
| 11:01:26 | mikal | sean-k-mooney: yeah, that's not going to happen tonight. That can be tomorrow Michael's problem. | |
| 11:01:33 | sean-k-mooney | :) | |
| 11:02:01 | sean-k-mooney | we sometimes put hte release not in the api patch that enabels the fucntionaltiy, we normlaly keep that to the end of the series by the way | |
| 11:02:03 | mikal | Either way I'd appreciate feedback, but I get that you're busy. I'll do release notes tomorrow before I move onto extra specs etc. | |
| 11:02:54 | sean-k-mooney | mikal: well the main feedback is you put the api change before the dirver change that implemted the feature | |
| 11:02:58 | sean-k-mooney | that is the wrogn order | |
| 11:03:03 | mikal | In my head the remaining patches (after the first three) are "more optional". You can live without USB redirection and sound if you need to. The feature is still useful to some people without those. | |
| 11:03:16 | sean-k-mooney | you need to put the api change at the end because once the api is intoduced the feature shoudl be useable fully | |
| 11:03:42 | sean-k-mooney | oh actully | |
| 11:03:49 | mikal | The feature should be fully usable after patch three. | |
| 11:03:57 | sean-k-mooney | ok ya i see | |
| 11:04:09 | mikal | (Technically patch 3 would work on its own, but the others were already up there). | |
| 11:04:16 | sean-k-mooney | the rest are sound, debuging and usb | |
| 11:04:22 | sean-k-mooney | ok then its fine as is | |
| 11:04:26 | mikal | Yeah, and I might drop debugging. I am undecided. | |
| 11:04:53 | sean-k-mooney | it proably does not need seperate debug log cofnig form our normal debug config | |
| 11:04:54 | mikal | Its so verbose (and so weird because its GTK debugging) that its useful sometimes, but you have to be quite sad to turn it on. | |
| 11:05:00 | sean-k-mooney | unless your very very verbose | |
| 11:05:09 | mikal | Its very very verbose debugs in the libvirt qemu logs. | |
| 11:05:26 | mikal | Its orchestrating qemu to write debug logs, not nova. | |
| 11:05:54 | mikal | It helped when I was reverse engineering some bits of the protocol and occasionally crashing the hypervisor. | |
| 11:06:02 | sean-k-mooney | mikal: oh ... | |
| 11:06:17 | sean-k-mooney | you are aware we don not allow wemu command line options to be used in nova right | |
| 11:06:21 | mikal | The SPICE protocol docs are... not good. | |
| 11:07:16 | mikal | sean-k-mooney: as in what happens in https://review.opendev.org/c/openstack/nova/+/922546/5/nova/virt/libvirt/config.py is banned? | |
| 11:07:20 | sean-k-mooney | so we cant procedd with https://review.opendev.org/c/openstack/nova/+/922546/5/nova/virt/libvirt/config.py | |
| 11:07:44 | mikal | That is a shame, because that feature is cool. | |
| 11:07:57 | mikal | But libvirt only exposed it as a command line flag. | |
| 11:08:12 | sean-k-mooney | then we need a livbirt chagne before we can support configuing tha tin nova | |
| 11:08:22 | sean-k-mooney | i have unfrutaly had to do that dance several times | |
| 11:08:24 | mikal | Its this -- https://www.spice-space.org/multiple-clients.html | |
| 11:09:01 | sean-k-mooney | if we use the qemu command elemets directly it marks the domain as tainted and voids all supprot form most distors virt teams | |
| 11:09:19 | sean-k-mooney | as a result we have had a strict ban on it upstream for as long as i have worked on openstack | |
| 11:09:38 | mikal | I thought secure boot required it too though? | |
| 11:09:45 | sean-k-mooney | nope | |
| 11:10:08 | mikal | Herm, I no longer remember why I believe that <qemu:arg value='-global'/><qemu:arg value='ICH9-LPC.disable_s3=1'/> is required with secure boot. | |
| 11:10:46 | mikal | Oh, its required for Windows 11 support I think... https://github.com/quickemu-project/quickemu/issues/220 | |
| 11:10:50 | sean-k-mooney | mikal: are you perhaps usign secvure boto with the pc machine type or somethign like that | |
| 11:11:43 | sean-k-mooney | mikal: becasue officaly secure boot is considered experimiantal unless your useing q35 | |
| 11:12:35 | mikal | sean-k-mooney: no, I'm definitely using q35 with secure boot. This wasn't in nova though, it was another code base. | |
| 11:13:01 | mikal | Said other code base just has three examples of qemu command line setting: this ICH9 thing; nvme disks; and concurrent SPICE sessions. | |
| 11:13:46 | sean-k-mooney | ich9 i thnk is either the dound device or the chipset | |
| 11:13:50 | mikal | Anyways, I can drop that patch from the series of Nova doesn't want to support concurrent SPICE sessions, its just a nice feature to have. | |
| 11:14:03 | mikal | Yeah, ICH9 is a sound device. | |
| 11:14:08 | sean-k-mooney | well we can supprot it but we need libvirt to supprot it first | |
| 11:14:23 | sean-k-mooney | mikal: ok well we dont add soudn device today if i recall | |
| 11:14:28 | mikal | Well, its an IO controller hub, which does sound. Its one of the libvirt sound model options. | |
| 11:14:56 | sean-k-mooney | yep i have plaied with the setting in virt-manager before | |
| 11:15:12 | sean-k-mooney | i just dont recall if we generate that upstream or not | |
| 11:15:47 | mikal | I'll just drop the SPICE concurrency patch for now. There is zero chance of me pursuing a libvirt patch right now. | |
| 12:46:39 | opendevreview | Merged openstack/nova stable/2024.1: Stop using split UEC image (mostly) https://review.opendev.org/c/openstack/nova/+/923831 | |
| 13:14:58 | frickler | sean-k-mooney: bauzas: grenade jobs are failing on the 2023.1 patch, but should grenade actually still run there when zed is eom? https://review.opendev.org/c/openstack/nova/+/924734 | |
| 13:16:40 | frickler | (seems more of the setuptools woe happening there) | |
| 13:16:51 | frickler | also https://zuul.opendev.org/t/openstack/build/c8fbe90f70974d2f918ee7fa6da54575 looks recheckable to me | |
| 13:19:44 | sean-k-mooney | frickler: we have debated that before. so its failign because of the setuptool issue right | |
| 13:21:14 | frickler | sean-k-mooney: the grenade failures that I looked at, yes. note the failure is on the controller, the later failure on compute1 is just secondary | |
| 13:21:46 | sean-k-mooney | i skimed them this morning and didnt see anytign really related to the patch | |
| 13:22:16 | sean-k-mooney | i didnt really look into test_get_list_deleted_instance_actions closely | |
| 13:23:24 | sean-k-mooney | Build of instance 38107228-1260-473d-b6a8-7f3148a135ce aborted: Failed to allocate the network(s), not rescheduling.: nova.exception.BuildAbortException: Build of instance 38107228-1260-473d-b6a8-7f3148a135ce aborted: Failed to allocate the network(s), not rescheduling. | |
| 13:23:36 | sean-k-mooney | ok so that is also unrelated | |
| 13:24:31 | bauzas | .... | |
| 13:31:32 | sean-k-mooney | frickler: so yes i think that will pass if we reject if the upper constraits bump for packaging has been merged | |
| 13:31:39 | sean-k-mooney | to fix the focal issues | |
| 13:38:19 | dansmith | ykarel: around? | |
| 13:39:06 | dansmith | oh I guess sean-k-mooney and ralonsoh have already discussed the image content failure | |
| 13:41:09 | ralonsoh | dansmith, most probably will change the neutron jobs to use qcow2 images, we are still testing | |
| 13:41:24 | dansmith | ralonsoh: excellent | |
| 14:15:55 | sean-k-mooney | dansmith: longterm we should fix tempets but that the short term solution. for our 2024.1 branch we have merge the revert back to qcow | |
| 14:16:11 | sean-k-mooney | and we had previously green result on 2023.2 | |
| 14:16:14 | dansmith | long-term we should drop ami/uec/whatever support :) | |
| 14:16:25 | sean-k-mooney | :) perhaps | |
| 14:16:49 | sean-k-mooney | alpine now provide cloud images by the way with cloud init in qcow format | |
| 14:17:16 | sean-k-mooney | so i might look at usign those instead of cirros again if we continue to see kernel panics | |
| 14:19:18 | sean-k-mooney | dansmith: a i saw you repsonded on https://bugs.launchpad.net/cinder/+bug/2073413 as well | |
| 14:19:44 | dansmith | yup | |
| 14:20:12 | sean-k-mooney | v2 qcow images might be safe if the lack of the feature mask means they cant have backing files | |
| 14:20:28 | sean-k-mooney | but if they can and we just didnt ahve a clean way to detech them before v3 | |
| 14:20:39 | sean-k-mooney | then im much less open to supprotign them going forward | |
| 14:22:23 | dansmith | yeah, I think they're probably safe here and we can exclude them, but I'm in no big rush to enable them.. that's pretty old at this point, none of the things I've tested use that old format (of course) and you can qemu-img convert your way to a v3 very easily | |
| 14:22:27 | sean-k-mooney | frickler: i can hack a poc of that i have a job that pull form my file share but i can likely just update the url | |
| 14:22:40 | dansmith | I'm working on a patch against oslo, but I don't think we need to apply it everywhere first | |
| 14:53:40 | ykarel | sean-k-mooney, wrt your alternate solution re. configure tempest for image create/upload | |
| 14:54:18 | ykarel | have you checked whoami-rajat comment regarding issue in format inspector? | |
| 14:54:45 | dansmith | ykarel: which issue? | |
| 14:54:46 | ykarel | as the images are created from snapshot, so tempest config doesn't seem involved here | |
| 14:54:56 | ykarel | dansmith, https://bugs.launchpad.net/nova/+bug/2073944 | |
| 14:56:08 | dansmith | ah | |
| 14:57:23 | dansmith | perhaps bfv instances and cinder is uploading always as raw even if it's qcow2? | |
| 14:58:45 | dansmith | or, cinder is setting the disk_format to ami, but uploading a qcow2 I guess | |
| 15:45:58 | ykarel | whoami-rajat, once around if you can check/confirm ^ | |
| 16:02:37 | opendevreview | Dan Smith proposed openstack/nova master: WIP: Remove AMI snapshot format special case https://review.opendev.org/c/openstack/nova/+/924866 | |
| 16:02:37 | opendevreview | Dan Smith proposed openstack/nova master: DNM re-enable UEC images for testing https://review.opendev.org/c/openstack/nova/+/924865 | |
| 17:04:05 | _colby | sean-k-mooney: bauzas: thanks. We were able to get instances running with the vgpu and the A40. Its still creating all the resource providers for every virtual function (event the ones not allowed/configured in nova) unlike the centos 8 machines. So we might have some issues with vgpu recycling and removing mdevs. Luckily for this host its going to be a single project using it and the vgpu sizes will stay the same. | |
| 17:05:29 | _colby | We are using the latest Nvidia vgpu drivers | |
| 17:09:55 | dansmith | melwitt: sean-k-mooney: early signs show that patch combo repro's and fixes the problem | |
| 17:11:24 | sean-k-mooney | dansmith: just back. that is good to hear | |
| 17:13:14 | dansmith | I need to fix unit tests | |