| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-26 | |||
| 16:41:03 | tkajinam | bauzas, yes | |
| 16:41:23 | dansmith | that seems like a big ask to me, | |
| 16:41:28 | tkajinam | I agree with the concern about reshape but I'm hoping that I at least get any feedback to hear how far it is from merge. | |
| 16:41:35 | dansmith | but I'm not really positioned to review a reshape | |
| 16:42:01 | tkajinam | we can discuss if that can be a subject to FFE or I'm even ok if that is eventually postponed to 2026.1 | |
| 16:42:10 | bauzas | I feel reasonable being able to review a reshape since I wrote two of them | |
| 16:42:26 | tkajinam | my main concern is that we've been saying the same for recent 2~3 cycles (if that's too much for this cycle and then put it to next) | |
| 16:42:36 | bauzas | but that's a very old knowledge part of myself I need to go with | |
| 16:42:41 | sean-k-mooney | bauzas: that would help because the rest of the serise is much more straght forward | |
| 16:43:00 | bauzas | sean-k-mooney: I can help with providing pointers to how the reshape mechanism works | |
| 16:43:18 | bauzas | from the very first glance I made on tkajinam's series, he perfectly managed it | |
| 16:43:36 | bauzas | I mean, he's triggerring the signal, and then using the signal to reshape | |
| 16:43:43 | sean-k-mooney | well thats encuraging at least. | |
| 16:43:44 | tkajinam | I added functional tests coverage according to the existing example so I hope that helps review... if any additional scenario may be needed I can try adding it | |
| 16:44:14 | bauzas | tkajinam: do you have any excerpts of a real environment upgrade scenario that you tested locally ? | |
| 16:44:22 | bauzas | I mean, pastebins | |
| 16:44:41 | bauzas | that would ease the review | |
| 16:45:19 | sean-k-mooney | you basiclly mean deploy devstack with out the patch and boot an sev instance then apply the patch adn restart nova right | |
| 16:45:32 | sean-k-mooney | to see it properly migrate the exsting allcoations | |
| 16:45:44 | bauzas | that yes | |
| 16:45:57 | bauzas | that's how I tested VGPU reshapes | |
| 16:46:57 | tkajinam | hmm I'll check but I'm afraid I didn't keep the test result logs, and it might take some time to spin up the env again (due to machine availability) | |
| 16:47:24 | bauzas | tkajinam: but I assume you tested such upgrade scenario, right? | |
| 16:47:42 | sean-k-mooney | as an asided there is an exsting bug that at least on rhel prevent sev form wroking. i aslo dont know if our internal amd host is free to do any testing | |
| 16:47:44 | bauzas | like, you had an env, you patched it, you saw the allocations moved | |
| 16:48:08 | tkajinam | yes, when I wrote the series initially. | |
| 16:48:11 | bauzas | excellent | |
| 16:48:18 | bauzas | and yeah, functional tests can prove it works | |
| 16:48:36 | bauzas | so if you already wrote them (I haven't reviewed them yet), that's excellent | |
| 16:48:57 | bauzas | tkajinam: I assume you found how to do it using the existing reshape methods? | |
| 16:49:22 | tkajinam | yeah | |
| 16:49:23 | tkajinam | https://review.opendev.org/c/openstack/nova/+/921814/32/nova/tests/functional/libvirt/test_reshape.py#233 | |
| 16:49:28 | bauzas | perfecty | |
| 16:49:33 | tkajinam | I followed the existing rehape test for mdev, IIRC | |
| 16:49:41 | bauzas | OK, I'll defineitely commit myself to the review then | |
| 16:51:47 | Uggla | ok shall we move on ? | |
| 16:51:58 | bauzas | yup, we'll see what we can do for the other bits | |
| 16:52:02 | bauzas | like every cycle | |
| 16:53:13 | Uggla | sure, what we have today is already cool. | |
| 16:53:37 | Uggla | so moving on. | |
| 16:53:40 | Uggla | #topic OpenAPI | |
| 16:53:47 | Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | |
| 16:53:58 | Uggla | #info still 32 remaining atm. | |
| 16:54:24 | Uggla | so this will probably not fully land in this cycle, but we made good progress. | |
| 16:54:40 | Uggla | #topic Stable Branches | |
| 16:54:55 | Uggla | elodilles, please go ahead. | |
| 16:55:01 | elodilles | #info stable branches (stable/2025.1 and stable/2024.*) seem to be in OK state | |
| 16:55:09 | elodilles | #info nova stable versions released: 29.3.0 (2024.1 Caracal); 30.1.0 (2024.2 Dalmatian); 31.1.0 (2025.1 Epoxy) | |
| 16:55:20 | elodilles | with the sec related bug fix from last week | |
| 16:55:35 | elodilles | and that's all from me for now, back to you Uggla | |
| 16:55:42 | Uggla | thx elodilles | |
| 16:55:46 | elodilles | np | |
| 16:56:17 | Uggla | skipping next point due to fwiesel pto's | |
| 16:57:03 | Uggla | I also guess we can skip gibi's point as I think he already covered previously. | |
| 16:57:20 | gibi | yepp nothing further for FF. I have things for post FF but we can disucss that next week | |
| 16:58:18 | Uggla | Yep we are at the top of hour. I know jssfr wanted to discuss, but I think we can do that next week. | |
| 16:59:08 | jssfr | did the UEFI NVRAM preservation thing also count as bugfix? | |
| 16:59:20 | sean-k-mooney | yes | |
| 16:59:25 | jssfr | okay, thanks | |
| 16:59:42 | sean-k-mooney | its not merged but we said we woudl treate the nvram and tpm data the same both as bug fixes | |
| 16:59:43 | jssfr | (even if not, it looks like y'all are busy enough getting all the other features over the line) | |
| 16:59:56 | jssfr | thanks, then we can certainly defer to next week from my side | |
| 17:00:05 | Uggla | jssfr thx. | |
| 17:00:11 | Uggla | So I'm gonna close, thanks all. | |
| 17:00:17 | Uggla | #endmeeting | |
| 17:00:17 | opendevmeet | Meeting ended Tue Aug 26 17:00:17 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:00:17 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-26-16.00.html | |
| 17:00:17 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-26-16.00.txt | |
| 17:00:17 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-26-16.00.log.html | |
| 17:00:54 | sean-k-mooney | Uggla: as an fyi i think we shoudl be able to merge at least the next 3 patches in the openapi seriese and possibly some more before FF | |
| 17:01:12 | sean-k-mooney | im also quitely hopeful we could land gmaan's service role change | |
| 17:01:34 | sean-k-mooney | i loooked at it today and after some back and forth on scope it looks good | |
| 17:01:35 | Uggla | yep me too, at least gmaan was quite confident about it | |
| 17:01:36 | bauzas | tkajinam: still here ? | |
| 17:01:43 | tkajinam | yes | |
| 17:02:08 | sean-k-mooney | gmaan has 3 DNM change that are running in ci agains neturon cinser and ironic that i wasnt to review before upgrading to a +2 | |
| 17:02:30 | Uggla | sean-k-mooney, it would be cool for the openapi too, even probably less a priority | |
| 17:02:59 | sean-k-mooney | i would really like to close that out htis cycle im just not sure how comnfortable people might be with a FFE for it. | |
| 17:03:16 | sean-k-mooney | i am plannign to try and compelte the review of the open patches but i have quite a few to go | |
| 17:03:22 | bauzas | tkajinam: do you understand that you could have a cloud with old computes and then placement reflecting two hosts with different inventories ? | |
| 17:03:50 | sean-k-mooney | Uggla: if it missies i woudl liek to keep the momentum up and continue to review/merge it after RC1 is cut | |
| 17:04:03 | Uggla | sean-k-mooney +1 | |
| 17:04:32 | bauzas | tkajinam: nothing should break, since old computes fulfilling AMD SEV requests would continue to be able to allocate them | |
| 17:04:49 | bauzas | new computes would be able to do that as well | |
| 17:05:02 | tkajinam | bauzas, you mean that a single cluster might have old computes reporting SEV in old structure while new ones reporting new structure | |
| 17:05:10 | bauzas | yup | |
| 17:06:43 | sean-k-mooney | we allow requests in the root group to be fullfiled by any RP in the tree right | |
| 17:07:22 | tkajinam | bauzas, yeah I understand that point. | |
| 17:07:23 | sean-k-mooney | so it shoudl be ok to come form a sub RP? or do we need to split it out for that to work? | |
| 17:07:30 | bauzas | I hope, but | |
| 17:07:45 | sean-k-mooney | i know we talked about that before i dont recall what it does today | |
| 17:07:57 | sean-k-mooney | if not we woudl ahve ot transfrom the SEV request ito a sepreate group | |
| 17:08:03 | sean-k-mooney | to suppro the mixed case | |
| 17:08:07 | bauzas | tkajinam: do you feel reasonably happy if I ask you amend your functional tests in https://review.opendev.org/c/openstack/nova/+/921814/32/nova/tests/functional/libvirt/test_reshape.py and provide a mixed environment ? | |
| 17:08:23 | sean-k-mooney | but i dont think that is required. | |
| 17:09:01 | bauzas | I mean, ideally I'd appreciate a test that would add a mixed scenario, ie. two computes with one being upgraded while the other one is not | |
| 17:09:13 | sean-k-mooney | this is something that an upgraded schduler is capable of doing however since we dont sue resouce: directly | |
| 17:09:50 | bauzas | tkajinam: do you think you could write such functional test quickly? | |
| 17:10:14 | bauzas | I just want to prevent any placement behavioural change I could have missed :) | |
| 17:11:00 | bauzas | and we would also ensure we don't regress, particularly if someone wants to change how placement is fulfilling requests | |