| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-12 | |||
| 18:15:34 | sean-k-mooney | bauzas: i have reviewd everything except the libvirt bump ill take a look at that now | |
| 18:15:48 | bauzas | <3 | |
| 18:16:05 | bauzas | I'll write the prelude patch tomorrow morning | |
| 18:17:53 | Uggla | bauzas, keep a little bandwith tomorrow morning to review the fup for Vf live migration. | |
| 18:18:02 | sean-k-mooney | so the bump patch is split in two right, the first does the bump and then https://review.opendev.org/c/openstack/nova/+/942872/2 is a follow up to drop the supprot for the older versions | |
| 18:18:21 | sean-k-mooney | so we can merge the bump and come back to the WIP patch next cycle yes | |
| 18:19:01 | Uggla | sean-k-mooney, yes. | |
| 18:19:36 | sean-k-mooney | ok i have appoved that as well and rechecked it for the timeouts | |
| 18:21:05 | Uggla | sean-k-mooney, I was running out of time for doing the cleanup this cycle. | |
| 18:21:34 | sean-k-mooney | thats ok. once we have signaled the new min version and updated the constants | |
| 18:21:43 | sean-k-mooney | the agent will check for the new min verison and report it | |
| 18:21:55 | sean-k-mooney | so we shoudl be fine | |
| 18:22:24 | Uggla | I hope too | |
| 18:26:35 | opendevreview | Merged openstack/nova-specs master: Move Epoxy implemented specs https://review.opendev.org/c/openstack/nova-specs/+/944019 | |
| 18:47:11 | bauzas | updated the cycle highlights : https://review.opendev.org/c/openstack/releases/+/943801 | |
| 18:49:22 | opendevreview | Dan Smith proposed openstack/nova master: Extend invalidate_rp to only invalidate cache https://review.opendev.org/c/openstack/nova/+/944148 | |
| 18:49:22 | opendevreview | Dan Smith proposed openstack/nova master: Support "one-time-use" PCI devices https://review.opendev.org/c/openstack/nova/+/943816 | |
| 18:49:23 | opendevreview | Dan Smith proposed openstack/nova master: Invalidate PCI-in-placement cached RPs during claim https://review.opendev.org/c/openstack/nova/+/944149 | |
| 20:42:11 | opendevreview | ribaudr proposed openstack/nova master: FUP Update pci-passthrough and virtual-gpu documentation https://review.opendev.org/c/openstack/nova/+/944153 | |
| 21:02:09 | opendevreview | Steve Baker proposed openstack/nova master: Add VNC console support for the Ironic driver https://review.opendev.org/c/openstack/nova/+/942528 | |
| #openstack-nova - 2025-03-13 | |||
| 10:47:18 | bauzas | gentle reminder that we have a couple of open patches that we need to merge before RC1 : https://etherpad.opendev.org/p/nova-epoxy-rc-potential | |
| 10:47:40 | bauzas | also, I'll be off today after noon CET (ie. in 15 mins) | |
| 12:11:50 | opendevreview | ribaudr proposed openstack/nova master: FUP improve and add integration tests for PCI SR-IOV servers https://review.opendev.org/c/openstack/nova/+/944106 | |
| 12:11:51 | opendevreview | ribaudr proposed openstack/nova master: FUP Update pci-passthrough and virtual-gpu documentation https://review.opendev.org/c/openstack/nova/+/944153 | |
| 12:11:51 | opendevreview | ribaudr proposed openstack/nova master: FUP Add a warning to make non-explicit live migration request debugging easier https://review.opendev.org/c/openstack/nova/+/944133 | |
| 12:32:34 | opendevreview | Merged openstack/nova master: doc: mark the maximum microversion for 2025.1 Epoxy https://review.opendev.org/c/openstack/nova/+/943948 | |
| 13:21:52 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce bug/2098496 https://review.opendev.org/c/openstack/nova/+/941673 | |
| 13:37:19 | opendevreview | Dan Smith proposed openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486 | |
| 13:37:56 | dansmith | bauzas: typo fix, if you could ^ | |
| 13:38:20 | dansmith | melwitt: I still think your +1 on that is useful if you want to re-add it (and I don't blame you, this is trial-by-PCI fire for me) | |
| 14:29:06 | opendevreview | Dan Smith proposed openstack/nova master: Add one-time-use devices docs and reno https://review.opendev.org/c/openstack/nova/+/944262 | |
| 15:29:44 | opendevreview | Balazs Gibizer proposed openstack/nova master: Ignore metadata tags in pci/stats _find_pool logic https://review.opendev.org/c/openstack/nova/+/944277 | |
| 15:29:44 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce bug/2098496 https://review.opendev.org/c/openstack/nova/+/941673 | |
| 15:31:13 | gibi | dansmith: just an FYI. This ^^ is the bugfix in the PCI in Placement codepath that fixes double allocations due to pool breakup | |
| 15:31:59 | dansmith | um, you say that like I should have context on that issue.. did we discuss this before? | |
| 15:32:16 | gibi | yepp in our last sprint planning downstream ;) | |
| 15:32:25 | gibi | you were interested in reviewing it | |
| 15:32:48 | gibi | the main issue is that if you have like 2 VFs per a single PF | |
| 15:32:52 | dansmith | okay I shall refresh myself :D | |
| 15:33:19 | gibi | and boot a VM requesting 1 VF, then delete the VM, and boot again the second VM will get 2 VFs instead of one | |
| 15:33:34 | dansmith | oh right right sorry | |
| 15:34:07 | gibi | the way the pci stats device pooling interacts with the placement driven PCI allocation leads some broken assumptions | |
| 15:34:43 | gibi | causing that the two VFs are broken up into two pools but both refer to the same placement RP | |
| 15:35:10 | gibi | while the other side of the code assumes that devices from a same RP are always in the same pool | |
| 15:35:54 | dansmith | I totally remember the conversation now, yep | |
| 15:36:07 | gibi | now both side of the code is improved. i) we avoid breaking up the pool ii) even if the pool is broken up in the future the other side of the code will be more graceful | |
| 15:36:27 | gibi | and not just allocate the same amount from each pool | |
| 15:45:04 | dansmith | okay I skimmed the repro thing.. I need to go learn about the pooling as I have a big gap there.. I'm also surprised this affects placement, but I guess because of some healing | |
| 15:45:42 | dansmith | but the "doesn't end up like we started" part of that makes sense of course | |
| 15:46:37 | sean-k-mooney | the pooling of the pci devices? | |
| 15:46:41 | gibi | sean-k-mooney: yepp | |
| 15:47:18 | gibi | dansmith: exactly I also think it affects placement due to healing, I will assert that in the repro.. | |
| 15:47:33 | sean-k-mooney | nova pci tracker kid of wors like placment but before placement was a thing. we summerised the "invetories" of devices into pools and that what we expose to the schduler | |
| 15:47:49 | sean-k-mooney | rather then all the devices on each host | |
| 15:47:55 | dansmith | I assume the pools are because of numa nodes or something? | |
| 15:48:08 | sean-k-mooney | not exactly | |
| 15:48:25 | sean-k-mooney | they are partly related ot that | |
| 15:48:39 | sean-k-mooney | btu they can be splcit on other thign liek neutron phsynet | |
| 15:49:06 | gibi | or rp_uui :) | |
| 15:49:11 | gibi | rp_uuid | |
| 15:49:28 | sean-k-mooney | ya that was grafted on after the fact for pci in placement | |
| 15:49:46 | gibi | dansmith: (confirmed locally that indeed the healing part breaks the placement view) | |
| 15:50:23 | sean-k-mooney | before a pool of VFs (think inventory of vfs) was group by the vendor id and product id, and i think parent and or phsynet? | |
| 15:51:04 | dansmith | but.. is there a pool object somewhere? seems like maybe they're just generated on the fly when we go to process a request? | |
| 15:51:12 | sean-k-mooney | yes | |
| 15:51:17 | sean-k-mooney | its stored in the comptue node table | |
| 15:51:31 | sean-k-mooney | that where the schdluer gets them form to add to the host state object | |
| 15:52:24 | dansmith | oh yeah I see | |
| 15:52:50 | dansmith | but this pci/stats thing (which seems not very related to stats) defines Pool as a dict | |
| 15:53:03 | sean-k-mooney | no its an ovo | |
| 15:53:07 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/pci_device_pool.py | |
| 15:53:12 | dansmith | I see that | |
| 15:53:27 | sean-k-mooney | well its stored as a json blob if that what your asking | |
| 15:53:28 | dansmith | https://review.opendev.org/c/openstack/nova/+/944277/1/nova/pci/stats.py line 39 | |
| 15:53:41 | dansmith | ^ is what I'm talking about | |
| 15:54:41 | sean-k-mooney | we convert it here https://github.com/openstack/nova/blob/master/nova/objects/compute_node.py#L321-L326 | |
| 15:55:04 | sean-k-mooney | which is called in save on the compute node here https://github.com/openstack/nova/blob/master/nova/objects/compute_node.py#L360 | |
| 15:55:22 | gibi | stats pool concept works with dict yes, the DB model works with jsonified ovos | |
| 15:55:52 | dansmith | and the PciDeviceStats seems to call a PciDevicePoolList "stats" | |
| 15:56:14 | sean-k-mooney | ya | |
| 15:56:15 | dansmith | which it then converts to a dict which it calls "pools" | |
| 15:56:20 | dansmith | wtf? | |
| 15:56:34 | sean-k-mooney | the nameing is shall we say in consitent | |
| 15:56:59 | dansmith | I was going to pick a different adjective.. possibly an emoji | |
| 15:57:22 | sean-k-mooney | the db colume is called pci_stats | |
| 15:57:24 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/db/main/models.py#L227-L229 | |
| 15:57:44 | dansmith | smh | |
| 15:57:52 | sean-k-mooney | the stats name came for the fact its a summary | |
| 15:58:00 | sean-k-mooney | i.e. a count and some metadata | |
| 15:58:05 | dansmith | so PciDevicePool has a product and vendor but not an address, | |
| 15:58:06 | sean-k-mooney | rather then each device | |
| 15:58:13 | sean-k-mooney | correct | |
| 15:58:29 | dansmith | so I assume we take the alias map and generate all the PciDevicePool objects we need with the appropriate count, even if count=1 because they just specified one address? | |
| 15:58:33 | sean-k-mooney | its a count of how many of that type of device (product/vendor) are avaible | |
| 15:58:50 | sean-k-mooney | yes | |
| 15:59:08 | sean-k-mooney | if the pci dev spec only allows 1 device you get a pool or 1 | |
| 15:59:12 | sean-k-mooney | *of 1 | |
| 15:59:16 | dansmith | this code is, I think, a very nice concrete example of why I normally just gloss over anytime PCI stuff comes up and try to ignore it :) | |
| 15:59:28 | dansmith | ack | |
| 15:59:53 | sean-k-mooney | i actully like this code partly becasue to me it very placement like | |