| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-11 | |||
| 16:07:52 | bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | |
| 16:08:01 | bauzas | anything to discuss about bugs ? | |
| 16:10:47 | bauzas | looks not | |
| 16:10:57 | bauzas | #topic Gate status | |
| 16:12:26 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:12:35 | bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | |
| 16:13:34 | bauzas | all periodics are green | |
| 16:13:41 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:13:48 | bauzas | #info Please try to provide meaningful comment when you recheck | |
| 16:14:24 | bauzas | anything about bugs ? | |
| 16:17:32 | Uggla | o/ | |
| 16:17:47 | bauzas | #topic Release Planning | |
| 16:17:54 | bauzas | #link https://releases.openstack.org/epoxy/schedule.html | |
| 16:18:01 | bauzas | #info Nova deadlines are set in the above schedule | |
| 16:18:12 | bauzas | #link https://etherpad.opendev.org/p/nova-epoxy-rc-potential | |
| 16:18:45 | elodilles | fyi the RC1 patches are already proposed: | |
| 16:18:49 | elodilles | https://review.opendev.org/c/openstack/releases/+/943941 | |
| 16:18:55 | elodilles | and | |
| 16:18:57 | elodilles | https://review.opendev.org/c/openstack/releases/+/943947 | |
| 16:20:11 | elodilles | (please add a -1 if something is in the queue to merge o:)) | |
| 16:20:20 | bauzas | nova-cores, please look at this etherpad, we have a number of patches to merge before we can propose RC1 | |
| 16:20:24 | bauzas | elodilles: will do | |
| 16:20:26 | bauzas | and saw those | |
| 16:20:31 | elodilles | thanks o/ | |
| 16:23:51 | bauzas | as a reminder, there is a section in the etherpad for adding bugfixes worth to be delivered | |
| 16:23:52 | dansmith | even without the upcoming baton change, probably best to let someone else run the meeting if you have a conflict | |
| 16:24:09 | bauzas | yeah it just went over for 24 mins :( | |
| 16:24:39 | bauzas | anyway, moving on | |
| 16:24:54 | bauzas | you'll see myself speaking in the channel asking cores to review thinfs | |
| 16:25:10 | bauzas | #topic PTG planning | |
| 16:25:28 | bauzas | #info Next PTG will be held on Apr 7-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 | |