| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-27 | |||
| 09:46:26 | gibi | no worries this is team work :) | |
| 10:04:29 | opendevreview | Merged openstack/nova stable/2024.1: Ignore metadata tags in pci/stats _find_pool logic https://review.opendev.org/c/openstack/nova/+/945101 | |
| 10:04:43 | opendevreview | Merged openstack/nova stable/2024.1: Update Nova bdm with updated swap info https://review.opendev.org/c/openstack/nova/+/937611 | |
| 11:02:25 | sean-k-mooney | gibi: so i belive if you call shutdwon on an executor pool that has pending task it just discards them | |
| 11:03:17 | sean-k-mooney | gibi: at least i belive that how the tread pools in the std lib concurrent.threadpool and process pool | |
| 11:04:49 | sean-k-mooney | gibi: whil i could not express point to this in doc this is part of the reason i orginallys asked that we do not rely on shutdown for the pool to finish all work. i wanted to keep a list of all the future for the exectuted tasks then wait for them to complete | |
| 11:06:42 | bauzas | sean-k-mooney: the SEV-ES is fully reviewed by me, I think we have a good opportunity to add that in Flamingo | |
| 11:07:07 | sean-k-mooney | bauzas: ok ill take a pass on it soon then | |
| 11:07:43 | sean-k-mooney | just sarting a littel late today, i got new ubiquit netowrking gear and may have bene up till 4 tweaking it.... | |
| 11:22:38 | gibi | sean-k-mooney: the python stdlib and the greenpool in futurist behaves the same and waits for all pending tasks, the futurist threadpool only waits for the running tasks not the queued ones. I think this is a bug in futurist as it should mimick the stdlib behavior | |
| 11:22:55 | gibi | sean-k-mooney: and yes we agreed that we should refactor the logic to be nicer than shutdown | |
| 11:23:02 | gibi | now we will have plenty of time for it | |
| 11:23:03 | gibi | :) | |
| 11:27:10 | gibi | still I will file a bug to futurist as this is a problem even for others switching from GreenThreadPoolExecutor to ThreadPoolExecutor within futurist | |
| 11:28:05 | sean-k-mooney | gibi: are you goign ot unparent the untit test form the conductor change if we are not proceedign with it | |
| 11:28:22 | gibi | yepp I will | |
| 11:28:40 | sean-k-mooney | ack did you seem my comment about the db transaction issue | |
| 11:28:44 | gibi | conductor will wait for Gazpatcho the unit test can go a bit if we want into F after FF | |
| 11:29:05 | sean-k-mooney | i think im just going to call that the GG release | |
| 11:29:10 | gibi | haven't seen the db comment yet, I will check, I assume it is abotu an unit test issue | |
| 11:29:20 | gibi | sean-k-mooney: hehe GG sounds good :) | |
| 11:29:38 | sean-k-mooney | so there was only one failing test case in the non voting zuul job patch | |
| 11:29:47 | sean-k-mooney | it passed on the next 2 | |
| 11:30:02 | sean-k-mooney | so either that test need to be after the fixture change | |
| 11:30:19 | sean-k-mooney | or its flaky under threading and need more investigation | |
| 11:30:30 | sean-k-mooney | so i was going to suggest adding it to the exclude list | |
| 11:30:45 | sean-k-mooney | i was tired last night so i didnt dign into the error much | |
| 11:31:50 | sean-k-mooney | gibi: i might do this as well but you may want to run it in a loop, im thinking of just letting the voting patch run in a loop executing unit test for an hour or so on my home server | |
| 11:32:27 | sean-k-mooney | actully i will kick that off now | |
| 11:42:51 | gibi | sean-k-mooney: I did run them in a loop locally. But I will investigate your comment | |
| 12:00:31 | sean-k-mooney | it was exactly 1 failng test so it could be just a one off cause by some test to test interaction | |
| 12:32:33 | opendevreview | Takashi Kajinami proposed openstack/nova master: Purge nested SEV RPs when SEV is disabled https://review.opendev.org/c/openstack/nova/+/958626 | |
| 12:39:27 | tkajinam | my bad. I though I run the whole functional tests but I didn't (and didn't caught some tests also needing update ) | |
| 12:39:32 | tkajinam | I thought * | |
| 12:53:55 | ralonsoh | sean-k-mooney, hello! maybe you missed my message about SR-IOV trusted VFs and MAC changing (https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/sriov-trusted-vfs.html) | |
| 12:56:07 | sean-k-mooney | ralonsoh: ya i didnt see it but i think we talked about it in the past | |
| 12:56:28 | sean-k-mooney | trusted vf shoudl not allow the mac to be changed form the guest | |
| 12:56:46 | sean-k-mooney | i think we talked about there beign a bug in one of the intel drivers? | |
| 12:57:24 | sean-k-mooney | the tursted vf spec allow the VF to be in promisous mode | |
| 12:57:38 | sean-k-mooney | so it can recive traffic that is not destented for its mack | |
| 12:57:53 | sean-k-mooney | but its mac shoudl be still enforced by nova/neutron to be the neutron port mac | |
| 12:59:03 | sean-k-mooney | the kernel dirver is free to rest the mack to all 0000 when the vm is stopped but if it is started again it shoudl be programed by nova/libvirt to the requsted mac again | |
| 12:59:20 | sean-k-mooney | changes to things like link state in the guest or phsysical on the host shoudl not impact the mac at all | |
| 13:00:24 | sean-k-mooney | chanign the mac in the guest shoudl not propagate to the vf in trusted mode and if it does i woudl consider that to be a security issue | |
| 13:00:37 | sean-k-mooney | specificly in the vendors PF and VF driver | |
| 13:01:40 | ralonsoh | sean-k-mooney, but port bonding (and MAC changing) is also considered in the nova spec | |
| 13:01:49 | sean-k-mooney | yes an no | |
| 13:01:54 | sean-k-mooney | what we were descibeing there | |
| 13:02:11 | sean-k-mooney | was the ablity to create a bond port in the guest with a diffent mac then what is on the VF | |
| 13:02:17 | sean-k-mooney | on the host | |
| 13:02:36 | sean-k-mooney | how this used to work is if you change the mac on the guest interface the host mac woudl remain the same | |
| 13:02:45 | sean-k-mooney | in ip tools | |
| 13:02:50 | sean-k-mooney | or ifconfig | |
| 13:03:05 | sean-k-mooney | btu the mac on the packet that was sent on the wire would be updated | |
| 13:03:25 | ralonsoh | sean-k-mooney, ahhhh I thought that if you add two interfaces to a bond (inside the VM) you also change the VF MAC | |
| 13:03:26 | sean-k-mooney | ralonsoh: i think that is what has changed | |
| 13:03:38 | sean-k-mooney | you can change the guest visable side | |
| 13:04:03 | ralonsoh | ahhhh so you can update the bond MAC but it will eventually use the VF MAC outside the VM | |
| 13:04:06 | ralonsoh | I didn't know that | |
| 13:04:12 | sean-k-mooney | btu on niantic for exampel that never actully changed the mac on the host side form the perspecitive of libvirt or ifconfig | |
| 13:04:38 | sean-k-mooney | it would change the mac on the wire which wi why it worked btu the comtople plane view was nto updated | |
| 13:04:58 | sean-k-mooney | i woudl assume at some point they hooked up the mailbox protocol to propagate the mac change | |
| 13:05:21 | ralonsoh | yeah, this is what is happening now | |
| 13:05:30 | sean-k-mooney | ralonsoh: ideaaly the sriov nic agent would use the pci adddress not the the mac/name | |
| 13:05:35 | ralonsoh | and this is of course an issue (at least from Neutron point of view) | |
| 13:05:58 | ralonsoh | sriov agent uses the MAC/PCI tuple to identify a port | |
| 13:06:04 | sean-k-mooney | is this the cause of the customer bug where tehy were seeing the state flap | |
| 13:06:19 | ralonsoh | yes | |
| 13:06:38 | sean-k-mooney | ah ok. im glad i updated that to the netwrokign team so :P | |
| 13:06:55 | sean-k-mooney | so ya i woudl consider just using the pci adress | |
| 13:07:07 | sean-k-mooney | the reason you check both is because of connectx-3 | |
| 13:07:15 | ralonsoh | so that would require a refactor of the sriov agent | |
| 13:07:19 | sean-k-mooney | in that generation of nic and only in that nic | |
| 13:07:39 | sean-k-mooney | you could have 2 pfs with the same pci adress | |
| 13:07:57 | sean-k-mooney | it was dumb and broke a bunch of other things and no one does that anymore | |
| 13:08:09 | ralonsoh | that's another story... | |
| 13:08:22 | ralonsoh | but of course, that won't work with ML2/SRIOV | |
| 13:15:20 | sean-k-mooney | ralonsoh: well just using the pci address shoudl work for ml2/sriov in general | |
| 13:16:08 | ralonsoh | sean-k-mooney, maybe, I need to check that. We need, at least, to write a warning if the expected MAC address is not set | |
| 13:16:41 | ralonsoh | how do I know a VF is used if I the MAC is the only thing I can check (for a PCI address) | |
| 13:16:59 | sean-k-mooney | you know its used by checkign the binding profile in the port | |
| 13:17:14 | sean-k-mooney | we pass the pci_slot | |
| 13:17:28 | sean-k-mooney | var which has the full pci adress | |
| 13:18:05 | ralonsoh | yes but I mean, in the SR-IOV agent we are detecting the port binding checking that the VF in a specific PCI has the expected MAC | |
| 13:18:24 | ralonsoh | and the MAC is set by nova compute | |
| 13:18:34 | sean-k-mooney | ya so it never actully needed to do that for what it worth | |
| 13:18:38 | ralonsoh | that was the trigger to send the vif-plugged event | |
| 13:18:47 | sean-k-mooney | orginally the sriov nic againe was entirly optional and not needed for intel nics | |
| 13:19:09 | sean-k-mooney | it was created by melanonx ot all managing things like link state via the admin state of the port | |
| 13:19:18 | sean-k-mooney | the mac programming to this day is done by nova | |
| 13:19:29 | ralonsoh | or qos or changing the propagation flag | |
| 13:20:01 | ralonsoh | I'll raise this issue in the Neutron community, I'll create a LP bug | |
| 13:20:08 | sean-k-mooney | as with everythign else the l2 part of the networing (seting the mac) is done by nova based on the mac set in the neutron port | |
| 13:20:13 | sean-k-mooney | ack | |
| 13:20:42 | sean-k-mooney | i think its fair to raise a warnign if it not the expectev version and its not using trusted VF | |
| 13:20:53 | sean-k-mooney | if it is then it shoud be info level IMO | |
| 13:21:58 | sean-k-mooney | maybe warning is valid but this is apprently vendor and drive rdependnet beahivor | |
| 13:22:22 | sean-k-mooney | warnings are normmly a call to arms for an operator to fix somethign and i dont think there is anything for them to fix in this case | |
| 13:22:32 | ralonsoh | warning is better than forcing the resync | |
| 13:22:44 | sean-k-mooney | oh im not saying we shoudl resync | |