| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-03 | |||
| 08:49:43 | kashyap | 'qemu-kvm' is the symlink on Fedora/CentOS | |
| 08:50:00 | sean-k-mooney | kashyap: not quite | |
| 08:50:12 | sean-k-mooney | well it might be a symlink but it was a script on ubuntu | |
| 08:50:22 | kashyap | /usr/bin/qemu-kvm: symbolic link to qemu-system-x86_64 | |
| 08:50:22 | kashyap | $> file /usr/bin/qemu-kvm | |
| 08:50:28 | songwenping | bauzas:if we create new mdev when alloc, there will be no this problem. | |
| 08:50:33 | kashyap | sean-k-mooney: Yeah, it used to be a wrapper script | |
| 08:50:40 | sean-k-mooney | yep | |
| 08:50:45 | kashyap | (Which just pointed to the real binary. So they removed that) | |
| 08:50:53 | sean-k-mooney | it was a wrapper on ubuntu in 20.04 | |
| 08:51:00 | sean-k-mooney | in 22.04 they droped it | |
| 08:51:44 | bauzas | songwenping: I don't see how it could help | |
| 08:51:59 | sean-k-mooney | kashyap: looks like ti snow a virtual package/metapackage https://packages.ubuntu.com/jammy/qemu-kvm | |
| 08:52:31 | sean-k-mooney | likely for upgrade reasons | |
| 08:53:05 | kashyap | Yeah, same on Fedora | |
| 08:53:19 | sean-k-mooney | kashyap: if you want to poke around i can give you access to the server just let me know | |
| 08:53:19 | kashyap | (contains no files) | |
| 08:53:19 | kashyap | $> rpm -ql qemu-kvm | |
| 08:53:55 | elodilles | gibi: for the sake of easier reviewing i'd say squash is better to avoid. some rare cases though we can have squash: e.g. in case otherwise we could not unblock the gate. or in case we can avoid some introduced bug that the follow-up fixes. | |
| 08:54:04 | kashyap | sean-k-mooney: Thank you, it's not needed at this time. I just wanted to be sure of the path - so that we could supply it to `coredumpctl` :) | |
| 08:54:27 | sean-k-mooney | hum never had to use that | |
| 08:54:39 | sean-k-mooney | does that parse them or cause them :) | |
| 08:55:05 | songwenping | bauzas: in this function https://github.com/openstack/nova/blob/8260979b71b29ce2666d37b3adc7c256482aa16d/nova/virt/libvirt/driver.py#L6416, we use _create_new_mediated_device for every vm instead of select a mdev from mdevs_available. | |
| 08:57:40 | sean-k-mooney | songwenping: we inteded to not reuse mdevs for new vms | |
| 08:57:54 | sean-k-mooney | the other path for intedd for agent restart if i rememebr correctly | |
| 08:58:11 | sean-k-mooney | songwenping: so we shoudl be delete the mdevs if we delete the vm | |
| 08:58:27 | songwenping | sean-k-mooney: cool | |
| 08:58:51 | sean-k-mooney | songwenping: this become more important for cards that can support more then one mdev at a time with generic mdev support | |
| 08:59:15 | sean-k-mooney | i dont think nvidia do with any of there gpus btu other vendors might in the future | |
| 09:00:22 | songwenping | sean-k-mooney: ack, agree to delete the mdevs if we delete the vm | |
| 09:00:22 | sean-k-mooney | bauzas: precrating does not work and i dont think it was part of the sepc so if that was added its a bug | |
| 09:00:31 | bauzas | sean-k-mooney: if we make nova creating the mdevs directly, this could create other problems | |
| 09:00:42 | bauzas | for reboot, for example | |
| 09:00:57 | sean-k-mooney | bauzas: we dont support using mdevctl and the current case faild our qe | |
| 09:01:03 | bauzas | remember the difference between SR-IOV devices and mdevs | |
| 09:01:09 | sean-k-mooney | bauzas: nova is not able to create the mdevs because it did not clean up | |
| 09:01:16 | sean-k-mooney | bauzas: yes i know | |
| 09:01:31 | sean-k-mooney | we only support nova creating the mdevs today | |
| 09:01:40 | sean-k-mooney | including in the mig case | |
| 09:02:00 | bauzas | in the mig case, nothing changes from nova pov | |
| 09:02:11 | bauzas | this is just that we precreate the pci devices | |
| 09:02:17 | sean-k-mooney | yep | |
| 09:02:17 | bauzas | not the mdevs | |
| 09:02:32 | songwenping | when manage vgpus by cyborg, we precreate the mdevs when discover | |
| 09:02:33 | sean-k-mooney | pre creat the pci device and list the vfs instead of the pf | |
| 09:02:45 | bauzas | songwenping: sean-k-mooney: anyway, I'm not against fixing this old bug | |
| 09:03:03 | bauzas | songwenping: if you have time for fixing it, would be appreciated | |
| 09:03:11 | bauzas | none of this requires a spec | |
| 09:06:54 | songwenping | bauzas:i'll try. | |
| 09:29:28 | kashyap | dansmith: To answer to your question in the scrollback: yeah, I'm guessing it's different - based on the trigger here (backup) vs. the older one (disk-detach) | |
| 09:32:08 | frickler | gibi: hacking-integration-nova has been busted for ages | |
| 09:32:58 | frickler | likely before we moved to zull v3 even https://zuul.opendev.org/t/openstack/builds?job_name=hacking-integration-nova&project=openstack%2Fhacking&result=SUCCESS&skip=0 | |
| 09:33:05 | frickler | *zuul | |
| 09:34:08 | opendevreview | Balazs Gibizer proposed openstack/nova master: Fix PciAddressSpec descendants to call super.__init__ https://review.opendev.org/c/openstack/nova/+/844565 | |
| 09:34:37 | gibi | frickler: I think it shows that nova is not compatible with latest hacking | |
| 09:34:43 | gibi | frickler: am I mistaken? | |
| 09:35:47 | frickler | gibi: this is true. afaict nova also hasn't been compatible with at least 3 years of previous releases of hacking, so not much change | |
| 09:36:09 | gibi | ahh OK | |
| 09:36:43 | gibi | frickler: so you think we can land the flake version bump after I drop py35 testing or we need to fix nova first? | |
| 09:37:57 | sean-k-mooney | frickler: gibi if we use black hacking become less importnat. still nice for extra non style related checks like dont improt prev sep stuff with from | |
| 09:38:13 | sean-k-mooney | or any other rules we want to enforece but the systle related ones are less requried | |
| 09:38:21 | gibi | sean-k-mooney: the current failures are thinks that are not covered by black / flake | |
| 09:38:43 | frickler | gibi: nova caps to 3.1.0, there are 3.2.0, 4.0.0 and 4.1.0 already. so adapting nova to recent hacking should not block updating hacking IMO | |
| 09:38:49 | sean-k-mooney | ack i was just hoping it would reduce the number of things we have to port | |
| 09:38:59 | gibi | frickler: thanks | |
| 09:39:08 | gibi | I will update the hacking patch to drop py35 then | |
| 09:39:16 | sean-k-mooney | frickler: yep it should not | |
| 09:40:45 | frickler | also I must reduce my "3 years" claim to 2 years, 3.1.0 was released in May 2020. no idea how far back our history of zuul builds actually goes | |
| 09:54:49 | sean-k-mooney | frickler: i think there was a change in hackign that broke some fo our checks which is why we pinned | |
| 09:55:10 | sean-k-mooney | frickler: but then stephenfin who was lookign at fixing it moved to not work on nova as part of there day job | |
| 09:55:17 | sean-k-mooney | and we had others move too | |
| 09:55:28 | sean-k-mooney | so we just never got aroudn to adressint the issues | |
| 09:55:46 | sean-k-mooney | we might still have patches form stephenfin for some of the issues | |
| 09:57:31 | sean-k-mooney | not that i can see on this topic | |
| 09:58:31 | sean-k-mooney | frickler: we did recently move to 3.1 | |
| 09:58:34 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/836639/1/.pre-commit-config.yaml | |
| 10:03:05 | sean-k-mooney | actully i guess the bump was done in victoria https://github.com/openstack/nova/commit/61b99a1295c5208deef806b69ba74a7d031ad851 | |
| 10:04:41 | frickler | sean-k-mooney: yes, that was right after the release of 3.1.0, but it seems after that, nova lost track | |
| 10:05:03 | sean-k-mooney | yep it was not broken so i guess we just never updated it | |
| 10:05:34 | sean-k-mooney | proably also just resouce constrianed/pandmic related | |
| 12:18:45 | sean-k-mooney | :) | |
| 12:19:27 | sean-k-mooney | dont you love how we only support bash globs if the adress is a sting and only support regexs if its a dictionary | |
| 12:20:35 | gibi | nah, the self.is_physical_function handling is worst in my eyes | |
| 12:21:04 | gibi | we write that flag twice based on two different utility function reading the same sysfs location | |
| 12:21:28 | sean-k-mooney | heh of course we do | |
| 12:21:30 | gibi | but yes, that string / dict duality is close second | |
| 12:22:03 | sean-k-mooney | we did it because of the conflict between * in glob and regex meendnin ins * is .* in regex land | |
| 12:22:16 | sean-k-mooney | i just wish we used regex form from the start | |
| 12:22:33 | gibi | yepp I figured that regex was added later and blow up the picture | |
| 12:22:54 | gibi | and of course the whole devname special case is a pain | |
| 12:23:08 | sean-k-mooney | i would not mind devname if it worked for all devices | |
| 12:23:17 | sean-k-mooney | but the fact that its unreliable and only works for nic | |
| 12:23:20 | sean-k-mooney | sometimes | |
| 12:23:25 | sean-k-mooney | is why i hate it | |
| 12:24:29 | sean-k-mooney | once you are done with the placment work i do still think its worth revisigint our config format in a differnt discussion | |
| 12:25:17 | gibi | I agree | |
| 12:25:36 | gibi | I will try to untangle as much of the current parsing code as possible before I add the new things to it | |
| 12:25:37 | sean-k-mooney | like in general can oslo config supprot yaml or can we add a resouces.yaml for all the complext host level resouces | |
| 12:26:15 | sean-k-mooney | ok cool | |
| 12:26:36 | sean-k-mooney | the other thing to be aware of is how we parse physical_network | |