| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-27 | |||
| 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: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814 | |
| 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: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: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:24 | opendevreview | Takashi Kajinami proposed openstack/nova master: Add functional test scenario for mixed SEV RPs https://review.opendev.org/c/openstack/nova/+/958562 | |
| 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 | |
| 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 | |
| 14:44:45 | dansmith | yeah the former is what I was thinking.. I know some may not even go that far, so I wish we had another venue but.. at least asking for success reporting seems like a good idea | |
| 14:45:01 | gibi | I will respin and add it | |
| 14:45:12 | gibi | (and in the same time I will remove the nova-conductor from the series) | |
| 14:45:18 | dansmith | maybe put bauzas' personal email and cell number (as our closest TC rep) in there if they don't want to join the ML :D | |
| 14:45:30 | gibi | lol :) | |
| 14:45:32 | bauzas | hmmm, WAT ? | |
| 14:45:33 | dansmith | gibi: also why not just squash those renos into one? | |
| 14:45:54 | bauzas | $context ? | |
| 14:46:00 | gibi | dansmith: about the renos there. We already have two from two independent patch but yeah I can try to merge them in that commit and see what our doc gen says about a deleted reno | |
| 14:46:21 | dansmith | not a big deal but when I read the second one I thought it was accidental duplication until I flipped back and forth a couple times to see | |
| 14:46:33 | dansmith | gibi: oh right, duh, okay nevermind then | |
| 14:47:41 | dansmith | usually renos in patches are new and I was reading it as if you were adding those.. no need to fix now I think | |
| 14:47:50 | gibi | OK | |
| 15:01:08 | gibi | Uggla: ping :) | |
| 15:02:21 | Uggla | gibi pong ! :) | |
| 15:02:48 | gibi | probably a netspilt happened between the IRC servers but those should be reported to us. At least in the univesity days that was somewhat frequent and that was a way to steal nicks :) | |
| 15:11:59 | bauzas | gibi: dansmith: what was the problem with reno ? sorry, hardly following | |
| 15:12:10 | dansmith | yeah I think after some netsplit my nick list just didn't recover.. I restarted my client and it's back now | |
| 15:12:13 | dansmith | bauzas: no problem | |
| 15:12:16 | bauzas | also, I'd appreciate if some cores could give a look at tkajinam's series on SEV ES | |
| 15:12:53 | bauzas | I reviewed that, Uggla found some typos that tkajinam will update but apart from that, we're in a very good spot to support next generation of AMD SEV :) | |
| 15:12:57 | dansmith | bauzas: as I said, I'm not reviewing that before tomorrow.. I'm totally blank on it and don't think I'd be doing a good job in such a short time frame... just FYI | |
| 15:13:22 | bauzas | dansmith: well, it was a general reminder to all of us, not particularly you who already said that indeed, cool | |
| 15:13:35 | dansmith | yep, I know, just sayin' :) | |