| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-21 | |||
| 06:33:27 | opendevreview | Arnaud Morin proposed openstack/nova master: Fix missing marker with instances in build_requests https://review.opendev.org/c/openstack/nova/+/947804 | |
| 06:34:51 | opendevreview | Stefan K proposed openstack/nova-specs master: Add Cloud Hypervisor support spec https://review.opendev.org/c/openstack/nova-specs/+/945549 | |
| 09:24:57 | sean-k-mooney | Uggla: there are 2 potential specless blueprint for use to consider https://blueprints.launchpad.net/nova/+spec/xml-image-meta which has an implemeation aviabel https://review.opendev.org/q/topic:%22bp/xml-image-meta%22 is the first | |
| 09:25:56 | sean-k-mooney | Uggla: the author reached out druing feature freeze and i chatted to them about it and gave some early feedback but they never procedurlly asked for the blueprint to be specless and for it to be reviewd | |
| 09:26:31 | sean-k-mooney | i suggested that they add it to the next meeting or ask for the approave via the mailing list if they cant attend | |
| 09:27:06 | sean-k-mooney | the ohter is more of a feature request but i think it could be specless https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/NSW3OG5ME5RDPQYLHF4T4RCWPQYG57PK/ | |
| 09:27:39 | sean-k-mooney | TLDR libvirt can now auto free ram allocated to a geust when the guest releases it internally. | |
| 09:27:55 | sean-k-mooney | you would not really want to do that for realtime vms | |
| 09:28:10 | sean-k-mooney | and you cant do it for hugepage/filebacked vms | |
| 09:28:32 | sean-k-mooney | but for standard vms we proably shoudl just enabel that always | |
| 09:28:54 | bauzas | sean-k-mooney: I need to go to the physio in 30 mins but if you have time, it would be nice if you could help me on https://review.opendev.org/c/openstack/nova/+/922140 | |
| 09:29:03 | sean-k-mooney | this is more just an fyi that thsoe would both eb low hanging fruite features. | |
| 09:29:43 | sean-k-mooney | bauzas: form the logs the last time it was pretty clear that the isseu was nto with the subnode using the wrong commit | |
| 09:30:20 | sean-k-mooney | i say you said that in the team meeting yesterday but that was no tthe problem previosuly, we coudl see the commit that was beign used in the job output on the ocmptue and it was correct | |
| 09:30:26 | sean-k-mooney | witht hat said sure i can take a look | |
| 09:30:59 | Uggla | sean-k-mooney, Ok I will add them to the doc and we will be able to discuss them in next meeting if it is required. | |
| 09:31:23 | sean-k-mooney | bauzas: i assume you have tired this locally? | |
| 09:37:27 | sean-k-mooney | bauzas: https://zuul.opendev.org/t/openstack/build/d31c2c01045a409a96d9dfd5e8aabbaa/log/job-output.txt#25980 so its defintly using the expected commit on the compute node | |
| 09:40:06 | sean-k-mooney | in the comptue node devstack logs we can also see the tat compilation is enabeld 2025-05-20 12:55:42.033 | ++ /opt/stack/nova/devstack/settings:source:2 : NOVA_COMPILE_MDEV_SAMPLES=True | |
| 09:40:51 | sean-k-mooney | mdevctl is also installed | |
| 09:43:09 | sean-k-mooney | looking at the compiel itesf there are some warning but apprently they were compled and loaded properly | |
| 09:43:11 | sean-k-mooney | https://paste.opendev.org/show/bcAgW92YFhDTcFs5QLDD/ | |
| 09:45:11 | sean-k-mooney | the probelm to me look more like libvirt has not detected the mdevs yet and we only see that on the compute beasue there is less of a delay between the devstack stages | |
| 09:46:10 | sean-k-mooney | if i had to guess movign the compilation and install earliyer in devstack or restarting libvirt might fix this. | |
| 09:50:51 | bauzas | sean-k-mooney: sorry I was not notified by my TheLounge instance | |
| 09:51:13 | bauzas | my main wonder is why compute1 says mtty_mtty is a wrong device | |
| 09:51:36 | bauzas | anyway, I need to go to the physio now :( | |
| 09:51:42 | sean-k-mooney | bauzas: ill push a patch while your away | |
| 09:51:56 | sean-k-mooney | we can see if moving the module install before installign libvirt fixes it | |
| 09:52:17 | bauzas | I don't think this is the problem but let's see | |
| 09:52:20 | sean-k-mooney | i think its due to caching fo the device and a race between nova-comptue starting and libvirt seeing the device | |
| 09:52:51 | sean-k-mooney | bauzas: well i confimed its usign the correct commit, the compile succeed and the kernel modules were loaded | |
| 09:53:03 | sean-k-mooney | so that means the issue is either on the libvirt side or in nova | |
| 10:22:18 | opendevreview | sean mooney proposed openstack/nova master: move compile earlier https://review.opendev.org/c/openstack/nova/+/950516 | |
| 10:23:24 | sean-k-mooney | if my intuition is correct then ^ will fix it but we may need to keep the compile in install dependin on if we have depenciy issues | |
| 12:27:53 | opendevreview | sean mooney proposed openstack/nova master: move compile earlier https://review.opendev.org/c/openstack/nova/+/950516 | |
| 14:24:58 | gibi | sean-k-mooney: dansmith: bauzas: FYI the oslo.service threading backend patch has been merged https://review.opendev.org/c/openstack/oslo.service/+/945720 | |
| 14:26:16 | dansmith | cool | |
| 14:30:15 | dansmith | gibi: pci-in-placement (I think) question | |
| 14:30:38 | dansmith | ...and I'm getting close to being able to do this again, so if you don't know what I'm talking about, I'll repro to show you exactly, but: | |
| 14:31:10 | dansmith | since I don't have a lot of identical pci devices to play with, I tried configuring two different ones with the same name for my flavor (they're equivalent, just not identical) | |
| 14:31:40 | dansmith | when I tried to boot with that flavor, I got an error about "only one pci request allowed".. I think it was pci-in-placement specific | |
| 14:32:36 | dansmith | I always thought one of the benefits of symbolic naming for the pci devices was so you could use something like "nvme256G" and even if you had multiple generations of hardware, you'd get a suitable device | |
| 14:32:58 | dansmith | is that a pci-in-placement restriction or am I mistaken about that normally working? | |
| 14:33:33 | gibi | is it two aliases with the same name but different request? | |
| 14:33:56 | dansmith | right | |
| 14:34:21 | gibi | https://bugs.launchpad.net/nova/+bug/2102038 | |
| 14:35:36 | gibi | it is definitely does not work with pci in placement. Without it it is accepted but based on Sean this never really fully worked there either | |
| 14:36:13 | bauzas | gibi: dansmith: in a current meeting but looking | |
| 14:36:14 | dansmith | hmm, okay | |
| 14:36:35 | dansmith | gibi: I thought you could also specify devices in alias by address, but maybe that's not right | |
| 14:36:35 | gibi | https://review.opendev.org/c/openstack/nova/+/944062 see the comments from sean-k-mooney | |
| 14:36:57 | gibi | dansmith: I don't have the full picture of this without PCI in Placement | |
| 14:37:07 | gibi | with PCI in Placement it is not trivial to support | |
| 14:37:11 | bauzas | are we talking of PCI aliases ? | |
| 14:37:17 | dansmith | okay I don't know if I agree with sean's comments about it never being intended to be supported | |
| 14:37:33 | sean-k-mooney | dansmith: no the alilas doe not have an adress | |
| 14:37:33 | gibi | as we cannot say OR between resouce classes in allocationa candidate query | |
| 14:37:48 | sean-k-mooney | dansmith:the devspec does but the alaise does not | |
| 14:37:59 | dansmith | I obviously wasn't closely involved with the early pci stuff, but I remember a conversation at a design summit about addresses specifically so you didn't have to commit all of one vendor/product | |
| 14:38:36 | sean-k-mooney | dansmith: that was rejected because the alsi is ment to eb the same on all hosts | |
| 14:38:49 | sean-k-mooney | and the adress woudl vary | |
| 14:39:08 | sean-k-mooney | you dont need to commit all of one vendor id and product id | |
| 14:39:14 | sean-k-mooney | you do the filtering in the dev spec | |
| 14:39:36 | sean-k-mooney | the alias is an abstraction like the resouce classs in placement | |
| 14:40:00 | bauzas | I think you can even star the devices | |
| 14:40:04 | bauzas | for the alias | |
| 14:40:38 | dansmith | okay digging back through old release config docs, I guess I'm thinking of the whitelist | |
| 14:41:05 | sean-k-mooney | ya the whitelists is now the devspec | |
| 14:41:10 | dansmith | it seems really unfortunate to not be able to construct a flavor that gets one of a set of multiple identical-enough devices | |
| 14:41:20 | bauzas | dansmith: it should | |
| 14:41:35 | sean-k-mooney | dansmith: you can | |
| 14:41:37 | bauzas | I don't get what we can't do | |
| 14:41:52 | bauzas | there are two different things | |
| 14:41:56 | bauzas | sec | |
| 14:42:17 | dansmith | oh, multiple aliases in the flavor with commas? | |
| 14:42:22 | sean-k-mooney | yes | |
| 14:42:23 | dansmith | and that will do one-of? | |
| 14:42:28 | dansmith | okay, gotcha | |
| 14:42:28 | sean-k-mooney | no | |
| 14:42:29 | bauzas | https://docs.openstack.org/nova/latest/configuration/config.html#pci.alias | |
| 14:42:47 | sean-k-mooney | in the flavor if you use commas that is asking for multipel devices | |
| 14:42:52 | sean-k-mooney | but not one of | |
| 14:42:55 | bauzas | in the alias, you can request PCI devices by vendor/product IDs | |
| 14:42:58 | dansmith | okay, so how do I do one of? | |
| 14:43:03 | sean-k-mooney | you cant | |
| 14:43:10 | sean-k-mooney | not with out breaking other things | |
| 14:43:18 | sean-k-mooney | well | |
| 14:43:30 | sean-k-mooney | ok so you can do one of via resouce classes an pci in placement | |
| 14:43:30 | bauzas | again, I don't see the problem | |
| 14:43:39 | dansmith | okay, so it _is_ a limitation that we can't do what I asserted above: a flavor that selects one of a set of identical-enough hardware | |
| 14:44:08 | sean-k-mooney | dansmith: identical enough for live migration means they device must be exactly the same | |
| 14:44:09 | bauzas | but we can say 'nvme256:1' in the flavor, right? | |
| 14:44:15 | sean-k-mooney | potentlaly down to the firmware level | |
| 14:44:55 | dansmith | sean-k-mooney: for things that care about live migration, but (a) I have two devices that are the same vendor/product but different firmwares *and* one supports crypto and the other does not, | |
| 14:45:10 | dansmith | so I'm sure qemu has to do more is-this-the-same-for-real checking if we expect that to work robustly | |
| 14:45:18 | bauzas | provided that alias would match different hardware based on the same alias combination (either the vendor/product id or a star, IIRC) | |
| 14:45:23 | sean-k-mooney | dansmith: right so you can requiest trait in the alias | |
| 14:45:36 | bauzas | but that requires PCI in placvement | |
| 14:45:48 | dansmith | bauzas: I only care about pci in placement :) | |