| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-27 | |||
| 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 | |
| 13:23:07 | ralonsoh | well, if the mac is changed and doesn't match with the Neutron port one, this is indeed a warning | |
| 13:23:08 | sean-k-mooney | im just sayign the log message shoudl maybe be at a lower level | |
| 13:23:26 | sean-k-mooney | ack | |
| 13:23:28 | ralonsoh | I'll raise the bug and propose a patch, we can decide this in the review | |
| 13:23:50 | sean-k-mooney | you could also cosnider deprecating trusted_vf.... | |
| 13:24:05 | ralonsoh | for sure, that should only happen with trusted VF | |
| 13:24:20 | ralonsoh | if the port is not trusted, this is for sure something more serious | |
| 13:24:28 | sean-k-mooney | i dont like that feature becasue we stilll have not fixed the fact it required you to write data to a field only nova shoudl modify | |
| 13:25:06 | sean-k-mooney | i.e. there shoudl be a seprate trunsted vF extention that does not require you to mess with the binding profile | |
| 13:25:20 | sean-k-mooney | since humans shoudl never write to that | |
| 13:25:55 | ralonsoh | sorry, I don't get your point here | |
| 13:26:23 | ralonsoh | Neutron does not set the VF trusted flag | |
| 13:26:26 | sean-k-mooney | the trusted VF feature required you to requet it by writign data to the binding:profile field | |
| 13:26:34 | ralonsoh | ahhh ok ok | |
| 13:26:40 | ralonsoh | now I understand | |
| 13:26:51 | sean-k-mooney | correct neutron does not a human has to inject data into a filed that only nova should modify | |
| 13:26:59 | ralonsoh | well, we have done this before (removing things from the binding profile) | |
| 13:27:00 | sean-k-mooney | there shoudl be a port extenion for it instead | |
| 13:27:08 | sean-k-mooney | yep | |
| 13:27:11 | ralonsoh | agree | |
| 13:27:21 | ralonsoh | ok, I'll open another LP bug heheheheh | |
| 13:27:25 | sean-k-mooney | it woudl be nice to finally fix this so we dont need custom policy for the binding:profile filed | |
| 13:27:34 | sean-k-mooney | thanks | |
| 13:55:33 | gibi | I'm cancelling the eventlet sync today for the sake of the FeatureFreeze. I'm not tracking anything that is critical for the FF from the eventlet-removal series. The nova-conductor change is blocked by a bug in futurist so that is moved to GG. | |
| 13:56:08 | dansmith | gibi: I'm just reading that now | |
| 13:56:21 | dansmith | futurist aside, we could just make a list of threads and wait for them manually right? | |
| 13:56:28 | gibi | dansmith: right | |
| 13:56:35 | dansmith | probably best to move to G anyway given it's not critical | |
| 13:56:38 | gibi | we have a list of futures we can wait on | |
| 13:56:45 | dansmith | ack | |
| 13:57:05 | gibi | I will file a futurist bug as it might effect us or others elswhere when we shutting down executors | |
| 13:57:19 | gibi | but that is also post FF :) | |
| 13:57:45 | sambork_ | gibi, ack, I will work on that after ff then | |
| 13:58:22 | opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | |
| 13:58:22 | opendevreview | Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814 | |
| 13:58:23 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | |
| 13:58:23 | opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | |
| 13:58:24 | opendevreview | Takashi Kajinami proposed openstack/nova master: Purge nested SEV RPs when SEV is disabled https://review.opendev.org/c/openstack/nova/+/958626 | |
| 13:58:24 | opendevreview | Takashi Kajinami proposed openstack/nova master: Add functional test scenario for mixed SEV RPs https://review.opendev.org/c/openstack/nova/+/958562 | |
| 14:00:09 | ralonsoh | sean-k-mooney, just a heads-up: https://review.opendev.org/c/openstack/neutron/+/926068 | |
| 14:00:25 | ralonsoh | we are already sending the "trusted" field in the port dict | |
| 14:01:22 | ralonsoh | I think we don't set it always (if the flag is not present). But if the flag is True or False, we send this new field since 2024.2 | |
| 14:09:56 | dansmith | gmaan: are you rebasing this for FF? https://review.opendev.org/c/openstack/nova/+/957578 | |
| 14:24:19 | sean-k-mooney | ralonsoh: oh nice | |
| 14:24:39 | sean-k-mooney | ralonsoh: so if we have not picked that up yes on nova we shoudl supprot it | |
| 14:25:00 | sean-k-mooney | ralonsoh: so ya looks like there are no nova patches to finish it | |
| 14:25:54 | dansmith | you know, I'm just realizing that we never merged this repro/fix for placement: https://review.opendev.org/c/openstack/placement/+/945464 | |
| 14:25:57 | sean-k-mooney | ralonsoh: so am i correct that htis can now be set on a port without modifying the binding:profile at all | |
| 14:26:01 | dansmith | gibi: ^ | |
| 14:26:25 | sean-k-mooney | dansmith: ya i have that open in a tab form last week | |
| 14:26:42 | sean-k-mooney | dansmith: i assume you would like to get that in this cycle | |
| 14:26:59 | gibi | dansmith: I can take a look quickly now | |
| 14:27:08 | sean-k-mooney | i can try and make time to review it too | |
| 14:27:10 | gibi | unfortunately I missed it completly | |
| 14:27:15 | dansmith | I wish it was already because the context is out of my head now.. but yes, would very much like to have it merged | |
| 14:28:33 | sean-k-mooney | looks like you adressed my main comments. i just discarded one i had pienidng because its not worth changign the patch for | |
| 14:29:01 | sean-k-mooney | dansmith: the answer to https://review.opendev.org/c/openstack/placement/+/945464/comment/0189c002_387845d8/ was just the test is doing to diffent things so i woudl have made it two tests | |
| 14:29:38 | sean-k-mooney | ill just ack tthat comment and we can leave it as is | |
| 14:32:14 | sean-k-mooney | the repoducer looks fine ill need to spen a littel more time on the actual fix but ill do that later today | |
| 14:32:17 | ralonsoh | sean-k-mooney, yes, you can rely on this flag instead of the port binding | |
| 14:32:28 | ralonsoh | we are setting now in both places (the field and port binding) | |
| 14:32:39 | ralonsoh | we'll remove the last one (port binding) once accepted in Nova | |
| 14:33:36 | sean-k-mooney | ack. ill add nova ot the bug and check with other if we are ok to fix and backport that as a security hardening bug | |
| 14:33:55 | sean-k-mooney | if not then ill propose doing it as a specless blueprint next cycle | |
| 14:42:49 | dansmith | gibi: I was going to ping our PTL, but ... https://review.opendev.org/c/openstack/nova/+/957424 | |
| 14:43:00 | gibi | dansmith: I'm +2 on both patch in placement about the overallocation. Thanks both was pretty clear. | |
| 14:43:01 | dansmith | I wonder if we should point them to a specific outlet (or outlets) to report success | |
| 14:43:07 | dansmith | gibi: sweet thanks | |
| 14:44:04 | gibi | dansmith: I can ask them to drop a mail to the ML or show up on IRC. | |
| 14:44:41 | gibi | probably ML is easier for them | |