| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-11 | |||
| 16:25:34 | bauzas | #link https://etherpad.opendev.org/p/nova-2025.2-ptg | |
| 16:25:39 | bauzas | and that's it | |
| 16:25:45 | bauzas | #topic Stable Branches | |
| 16:25:49 | bauzas | elodilles: please | |
| 16:25:54 | elodilles | yepp | |
| 16:26:01 | elodilles | nothing special to report: | |
| 16:26:10 | elodilles | #info stable gates seem to be healthy | |
| 16:26:15 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:26:25 | bauzas | cool | |
| 16:26:32 | elodilles | (and we have some stable/2025.1 already) | |
| 16:26:32 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:26:46 | bauzas | fwiesel seems not to be present | |
| 16:26:49 | bauzas | moving on then | |
| 16:26:56 | bauzas | #topic Open discussion | |
| 16:27:03 | bauzas | nothing in the agenda | |
| 16:27:07 | bauzas | anything anyone ? | |
| 16:30:06 | opendevreview | mitya-eremeev-2 proposed openstack/nova master: Add more thorough handling of evacuated instances https://review.opendev.org/c/openstack/nova/+/944058 | |
| 16:30:44 | bauzas | looks we can close the meeting | |
| 16:30:46 | bauzas | thanks all | |
| 16:30:48 | bauzas | #endmeeting | |
| 16:30:48 | opendevmeet | Meeting ended Tue Mar 11 16:30:48 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:30:48 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-11-16.02.html | |
| 16:30:48 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-11-16.02.txt | |
| 16:30:48 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-11-16.02.log.html | |
| 16:31:12 | dansmith | bauzas: ack on the previous going over, sorry I just assumed you meant you intended to be superman and run two meetings at once :P | |
| 16:31:13 | elodilles | thanks o/ | |
| 16:31:41 | bauzas | dansmith: well, I really have no choices | |
| 16:31:59 | bauzas | hence myself leaving the hot seat, or I was about to burn | |
| 16:38:26 | ratailor | melwitt, could you please review https://review.opendev.org/c/openstack/nova/+/873901 and provide your feedback ? | |
| 16:38:59 | ratailor | gibi, could you please remove -1 here https://review.opendev.org/c/openstack/nova/+/933107 and provide your feedback ? | |
| 16:45:01 | gibi | ratailor: done | |
| 16:45:29 | ratailor | gibi, Thanks! | |
| 17:13:18 | dansmith | gibi: if you're still around.. it looks to me like we don't do all the "is this a physical function?" checking if the devspec is a pattern instead of a single device | |
| 17:14:02 | dansmith | I assume because there could be multiple things matched that have different characteristics | |
| 17:14:27 | dansmith | so you think we need to examine all the matching ones so we can abort if your spec matches a VF? | |
| 17:16:09 | gibi | auch. Yeah you are right, at that point we only have the dev_spec that can be wildcard and match to multiple devices. I'm not sure how the remote managed check below works then as that does some physical function check. Anyhow that means we cannot validate that input in at the device_spec parsing code and need to add it later in the pci_placemenet_translator | |
| 17:16:23 | dansmith | gibi: it just punts for patterns | |
| 17:16:36 | gibi | OK | |
| 17:16:40 | dansmith | gibi: well, my translator code already skips VFs | |
| 17:16:42 | gibi | not nice but meh | |
| 17:16:58 | dansmith | meaning, it won't reserve for VFs.. I could log something there though | |
| 17:17:43 | sean-k-mooney | we determin if its a phsyica function by looking at the libvirt nodedev xml when generiging the set of pci dicts and then we filter those by the devspec regexes ectra | |
| 17:17:45 | gibi | dansmith: yeah I think we can check in the translator that if the OTU is requested for a VF as that is clearly invalid. Currently your code ignoring it but that is missleading as the user expects that the OTU marked device will be reseved but it won't be | |
| 17:18:06 | gibi | so I suggest to raise there and let the deployer know that what is requested not supported | |
| 17:18:09 | dansmith | gibi: you mean the deployer.. the user can't see any of this | |
| 17:18:14 | dansmith | but okay | |
| 17:18:18 | gibi | yeah the deployer | |
| 17:18:19 | gibi | sorry | |
| 17:18:55 | gibi | I think we already have late input validation for the dependend device handling in the translator (when both the PF and its VFs are matched) | |
| 17:19:03 | dansmith | okay | |
| 17:19:43 | gibi | https://github.com/openstack/nova/blob/0d484ce37d86e989c8abdf57aec5e334f68206ef/nova/compute/pci_placement_translator.py#L146-L151 | |
| 17:21:08 | dansmith | gibi: okay so that's where we try to add children, and explode if we already have the parent? so I can just check OTU there and refuse similarly I guess? | |
| 17:21:50 | sean-k-mooney | add child is passed a pcidevce object so it could have also checked dev.dev_type | |
| 17:22:34 | dansmith | but no need to even check because if we're calling add_child and one_time_use=true, then fail right? | |
| 17:24:06 | sean-k-mooney | i mean you can fail there that pretty late | |
| 17:24:39 | dansmith | right but, see above.. when we're checking the devspec early, we don't have enough into to make a determination for patterns | |
| 17:25:02 | sean-k-mooney | dansmith: the devspec cant be used to tell if its a pf | |
| 17:25:15 | dansmith | ...right, I understand | |
| 17:25:23 | sean-k-mooney | but the device we get back form the driver alredy know if its a pf or not | |
| 17:26:44 | sean-k-mooney | i think you cna check in here https://github.com/openstack/nova/blob/0d484ce37d86e989c8abdf57aec5e334f68206ef/nova/pci/manager.py#L111 | |
| 17:28:28 | gibi | yeah you can check it in the pci manager as well. There we also have the both the dev and it's matching dev_spec | |
| 17:28:50 | sean-k-mooney | right roughtly here https://github.com/openstack/nova/blob/0d484ce37d86e989c8abdf57aec5e334f68206ef/nova/pci/manager.py#L135 | |
| 17:29:37 | sean-k-mooney | dev is the list of dicts form the virt driver and pci_dev_spec is the matched spec | |
| 17:29:55 | dansmith | okay | |
| 17:30:15 | sean-k-mooney | so here the dict has been encreced by the tags form the devspec https://github.com/openstack/nova/blob/0d484ce37d86e989c8abdf57aec5e334f68206ef/nova/pci/manager.py#L140 | |
| 17:30:30 | sean-k-mooney | and you can add a check before we add it to the devices list | |
| 17:31:30 | sean-k-mooney | you will need to add onetime use here https://github.com/openstack/nova/blob/master/nova/pci/devspec.py#L419 as well | |
| 17:31:41 | gibi | I would do it in the translator where you filter the VFs out that is the closest to the actual logic assuming no VFs are OTU | |
| 17:32:17 | sean-k-mooney | the translator is not the only place we do filtering but that an option yes | |
| 17:32:36 | gibi | the OTU feature hard depends on the translator | |
| 17:32:49 | gibi | it acutally implementes the OTU reservation | |
| 17:33:21 | sean-k-mooney | ya which is weiered to me because i expect this to really be done in the pci manager | |
| 17:33:25 | gibi | as we cannot put it early in the dev_spec parsing, the second best thing for me would be to put the check to the same place where the reserveation logic is | |
| 17:33:29 | sean-k-mooney | but i get why its doen that way | |
| 17:33:48 | dansmith | gibi: yeah that feels a lot cleaner to me, just because it's so contextually-relevant there | |
| 17:33:57 | gibi | if we implement OTU with the PCI tracker then I would agree with you, but we are going with implementing it in Placement | |
| 17:34:04 | gibi | dansmith: yepp | |
| 17:34:40 | sean-k-mooney | i kind of hate that we have any pci logic out soid eof the pci and hardware.py modules but that ship has sailed... | |
| 17:38:11 | gibi | sean-k-mooney: it is not hard to move the pci_placement_translator under the pci module | |
| 17:39:03 | opendevreview | Balazs Gibizer proposed openstack/nova master: Add functional reproducer for bug 2102038 https://review.opendev.org/c/openstack/nova/+/944061 | |
| 17:39:04 | opendevreview | Balazs Gibizer proposed openstack/nova master: Multiple spec per PCI alias limitation https://review.opendev.org/c/openstack/nova/+/944062 | |
| 17:55:40 | sean-k-mooney | ^ is not valid config | |
| 17:56:54 | sean-k-mooney | gibi: we can have two differntly named aliases refer to the same vedor_id and product_id | |
| 17:57:11 | sean-k-mooney | but you cant have 2 alises with the same name and differnt contett | |
| 18:00:21 | gibi | sean-k-mooney: you can :) | |
| 18:00:32 | gibi | not with PCI in Placement but without it | |
| 18:00:46 | sean-k-mooney | it was a bug if it was ever there | |
| 18:00:51 | sean-k-mooney | it was never inteded to be supproted | |
| 18:00:52 | gibi | the spec in the alias is a list | |
| 18:00:56 | sean-k-mooney | yes | |
| 18:01:03 | sean-k-mooney | but that is so you can define multiple | |
| 18:01:21 | gibi | nope a single named alias can have a list of attached spec dicts | |
| 18:01:24 | sean-k-mooney | it was always ment to map to exactly one value | |
| 18:01:37 | sean-k-mooney | that not how it was intended to work | |
| 18:02:13 | gibi | I have to drop now but we can discuss it tomorrow | |
| 18:03:05 | gibi | https://github.com/openstack/nova/blob/0d484ce37d86e989c8abdf57aec5e334f68206ef/nova/pci/request.py#L172 | |
| 18:03:19 | gibi | this is very nova appends more spec to the same alias | |
| 18:03:52 | gibi | s/very/where/ | |
| 18:04:02 | sean-k-mooney | ya i just found that | |
| 18:04:21 | sean-k-mooney | i can tell you tha tthat is very problematic | |