Earlier  
Posted Nick Remark
#openstack-nova - 2025-08-26
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 bauzas I mean, the zuul config change will be meaningless
16:34:07 sean-k-mooney ok that should nto block the code change
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 tkajinam :-)
16:39:01 bauzas okayu
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 sean-k-mooney so i think taht woudl be good to try and land
16:39:46 dansmith Uggla: land...in the next two days?
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
16:55:42 Uggla thx elodilles

Earlier   Later