| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-26 | |||
| 16:31:47 | sean-k-mooney | i was going to suggest rebasign the 6 packages on top of the conductor one | |
| 16:31:55 | bauzas | and I think those would be more beneficial for the rest of the work we have to do | |
| 16:32:09 | bauzas | sean-k-mooney: you mean, on the bottom ? | |
| 16:32:13 | sean-k-mooney | no | |
| 16:32:18 | gibi | sean-k-mooney: yeah that what I meant by arranging to get test results | |
| 16:32:36 | sean-k-mooney | because i disagree that havign the ablity to run the condcutor in treading mdoe is less valuable | |
| 16:33:03 | gibi | sambork: Are you around? ^^ :) | |
| 16:33:04 | sean-k-mooney | if we have the conductor patch we can test it and ask operator to test it and report bugs | |
| 16:33:08 | bauzas | if wre're not able to run it in CI, what's the benefit ? | |
| 16:33:17 | sean-k-mooney | we can trivially | |
| 16:33:26 | sean-k-mooney | its liktrally a 1 line change to the zuul job | |
| 16:33:37 | sean-k-mooney | to set the var in devstack to enabel threading mode | |
| 16:33:44 | bauzas | but we won't execute that code, right? | |
| 16:33:50 | gibi | sean-k-mooney: I think what bauzas imply is that we don't have tempest coverage for the changed code path | |
| 16:34:07 | sean-k-mooney | ok that should nto block the code change | |
| 16:34:07 | bauzas | I mean, the zuul config change will be meaningless | |
| 16:34:23 | bauzas | if we don't have zuul jobs that call image caching | |
| 16:34:25 | sean-k-mooney | its wont be it makes sure everythign else in the conductor works | |
| 16:34:39 | sean-k-mooney | i.e. that we are not implcitly relying on eventlet indrectly | |
| 16:34:53 | bauzas | that is a good point | |
| 16:35:12 | bauzas | we could have missed other eventlet dependencies | |
| 16:35:25 | bauzas | I then agree, | |
| 16:35:27 | sean-k-mooney | by the way i think we could land both if we are willing to merge the unit test change up to RC1 | |
| 16:35:51 | sean-k-mooney | my suggesting is for gibi to rebase them so we get more results today/tomorrow | |
| 16:36:01 | bauzas | agreed, I like that approach | |
| 16:36:03 | sean-k-mooney | and then we can decied if we are comfrotabel with merging the conductor changes | |
| 16:36:05 | gibi | I will do the rebase today to get unit test results with threadin on image cache | |
| 16:36:11 | bauzas | thanks gibi | |
| 16:36:14 | gibi | sambork: ^^ FYI | |
| 16:36:29 | sean-k-mooney | gibi: can we add the devstack job change too if you or sambork have time | |
| 16:36:32 | gibi | I will do local testing of the lock explicitly | |
| 16:36:37 | gibi | sean-k-mooney: I will do so | |
| 16:36:41 | sean-k-mooney | +1 | |
| 16:37:41 | gibi | I have nothing further | |
| 16:38:05 | Uggla | asking again, assuming gibi is working on the eventlet refactor any chance to land something in the above list ? Can we define some priorities/owners about them ? | |
| 16:38:37 | bauzas | about the other things to review, I want to speak about SEV-ES | |
| 16:38:46 | bauzas | but tkajinam is not here I guess (and hope) | |
| 16:38:56 | tkajinam | I am | |
| 16:38:59 | bauzas | wow | |
| 16:39:01 | bauzas | okayu | |
| 16:39:01 | tkajinam | :-) | |
| 16:39:27 | sean-k-mooney | stephenfin: and i both were interested in the sev one as well | |
| 16:39:38 | sean-k-mooney | or at least started looking at ti | |
| 16:39:46 | dansmith | Uggla: land...in the next two days? | |
| 16:39:46 | sean-k-mooney | so i think taht woudl be good to try and land | |
| 16:40:10 | bauzas | my concern is that we're on a non-SLURP release | |
| 16:40:20 | sean-k-mooney | but the main problem with that serise is reviewing the reshape | |
| 16:40:43 | bauzas | tkajinam: I assume you know that you'll have to continue to handle the reshape case for at least two releases, right? | |
| 16:40:49 | Uggla | dansmith yes if possible. | |
| 16:40:58 | Uggla | or at least try. | |
| 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 | |