Earlier  
Posted Nick Remark
#openstack-nova - 2025-08-26
16:00:31 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:31 opendevmeet Meeting started Tue Aug 26 16:00:31 2025 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:31 Uggla #startmeeting nova
16:00:37 elodilles o/
16:00:47 dansmith o/
16:00:56 Uggla Hello everyone
16:02:07 gibi o/
16:02:21 Uggla Let's start.
16:02:30 Uggla #topic Bugs (stuck/critical)
16:02:41 Uggla #info No Critical bug
16:02:49 Uggla #topic Gate status
16:02:58 Uggla #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:03:06 Uggla #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:03:10 tkajinam o/
16:03:19 Uggla #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status
16:03:31 Uggla #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:03:36 Uggla #info Please try to provide a meaningful comment when you recheck
16:03:39 bauzas o/
16:04:01 Uggla skipping next point as gmaan, is in another meeting.
16:04:16 Uggla topic Release Planning
16:04:28 Uggla #link https://releases.openstack.org/flamingo/schedule.html
16:04:34 Uggla #info Nova deadlines are set in the above schedule
16:04:48 Uggla #info Feature freeze is Thursday.
16:05:06 Uggla #topic Review priorities
16:05:14 Uggla #link https://etherpad.opendev.org/p/nova-2025.2-status
16:05:57 gibi Uggla: Am I correct that FF is on Thurday EOD, whathever apporoved can still rebased / rechecked after to land? Do we plan any FF exception process?
16:05:58 Uggla First I need to thank bauzas, who helped me to better highlight status in the board and sync correctly within launchpad.
16:06:38 bauzas well, I should have given you some help way before
16:07:19 Uggla gibi, I think so. I don't think exception will be needed but we might discuss it here.
16:07:44 Uggla Before that here are the review priorities we identified:
16:07:52 Uggla #link Amd Sev serie (tkajinam) need review https://review.opendev.org/q/topic:%22bp/amd-sev-es-libvirt-support%22
16:07:59 Uggla #link https://blueprints.launchpad.net/nova/+spec/copy-applied-provider-yaml https://review.opendev.org/c/openstack/nova/+/957578
16:08:06 Uggla #link https://blueprints.launchpad.net/nova/+spec/libvirt-migrate-parallel https://review.opendev.org/c/openstack/nova/+/950667
16:08:19 Uggla #link https://blueprints.launchpad.net/nova/+spec/policy-service-role-default one patch to review https://review.opendev.org/c/openstack/nova/+/957578
16:09:32 Uggla I discussed latest one with gmaan and that might land if we review it. (only one patch)
16:10:08 Uggla bauzas and I are currently reviewing Amd sev series.
16:10:48 sean-k-mooney o/
16:11:15 gibi Uggla: I'm currently try to squeez in https://review.opendev.org/c/openstack/nova/+/957088 before FF
16:11:27 gibi the rest of the eventlet series can wait post FF / G
16:11:57 bauzas my only concern is that AMD SEV-ES series requires a reshape
16:12:03 Uggla gibi, thanks that was one of the question I had.
16:12:14 dansmith gibi: you said you were fine with the content on that one, but...no unit tests?
16:12:17 bauzas this requires a lot of caution
16:12:18 dansmith are those coming?
16:12:26 sean-k-mooney Uggla: techihnaly teh parla clodu migration chnag eis for 2026.1
16:12:45 bauzas the what ?
16:12:47 sean-k-mooney or did we approve it late for this cycle
16:12:50 gibi dansmith: it is a refactor like the scatter gather change
16:13:01 gibi dansmith: I don't see what extra unit test we need
16:14:19 bauzas well, yes and no
16:14:21 dansmith okay I guess I thought something has to change with those mechanics, but I'll go look at what is testing this to see
16:14:37 bauzas there is a refactor but there is also a slight behavioral change
16:15:47 dansmith the lock obviously isn't verified, but if it's being run over then maybe that's okay
16:17:02 gibi the change is the lock and I want to verify that locally. If you need a functional test to ensure that lock is valid then sure we can do that too
16:17:22 gibi I don't see any other change in logic
16:18:58 bauzas I guess having such an invasive change without any single line of nova/tests made me afraid and I missed the point of the refactor
16:19:12 gibi invasive? you mean a lock?
16:19:30 gibi I'm confused
16:19:56 gibi I thought the goal of the refactor is not to change behavior so if the existing test does not need to be touched that is actaully good
16:20:23 gibi as it proves no behavior change happened
16:21:23 dansmith gibi: I guess I expected to see at least something running this code in both modes, but perhaps I'm jumping the gun there. I know we don't have that for everything we're thread-ifying, but this is also sort of a self-contained example
16:21:49 bauzas gibi: I agree with the fact that until some env var is set, nothing changes
16:21:49 sean-k-mooney so it would be nice to have the zuul change to enable it in the condutore in the patch
16:22:10 sean-k-mooney but i dont consider that an invasive change either for what its worth
16:22:11 gibi dansmith: yeah we did not transformed the unit test to both modes as part of the changes but we did it separately.
16:22:24 bauzas but yeah, I'd have appreciated some guideline to temper my guts
16:22:32 sean-k-mooney its adding a lock that shoudl techenically have been there even under eventlet + swapting the executor we use
16:22:34 dansmith unlike general thread spawning, this is a self-contained create/destroy of a single executor pool, which means we could test both modes here and now which is kinda what I was expecting
16:23:01 dansmith but that's fine
16:23:22 gibi dansmith: I will check my unit test enalbing series if it enables the related tests already...
16:23:42 gibi with threading in a separate tox target
16:24:37 sean-k-mooney what was that job called by the way
16:24:45 sean-k-mooney i tough we already enabled that in ci
16:24:53 sean-k-mooney is that still pending?
16:24:57 gibi nova-tox-py312-threading
16:25:00 gibi it is pending
16:25:04 gibi https://review.opendev.org/c/openstack/nova/+/955791/9
16:25:06 sean-k-mooney ah ok
16:25:26 sean-k-mooney sorry i tought that was earlier in the series
16:25:36 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/953475/20 that one right
16:25:45 Uggla 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:26:21 sean-k-mooney there are a number of the ci/testing changes that woudl be nice to also land
16:26:25 gibi dansmith: I see multiple image cache unit test passing in https://4d426b9917a9f7962308-d3c6167007a6d8477c4cec901604a1c7.ssl.cf1.rackcdn.com/openstack/4beb6e364cb74aaeb2b8ff0b475d966f/testr_results.html with threading. So if we move the refactor under the unit test series we can verify the change
16:26:37 sean-k-mooney but i wonder if we woudl be oke with some of those happening post FF
16:27:01 dansmith gibi: ack
16:27:17 gibi sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/953475/20 adds the job, but later patches enables more and more tests
16:27:21 sean-k-mooney the 6 patches including and up to https://review.opendev.org/c/openstack/nova/+/955791/9 are strech goals for me
16:27:42 gibi yeah the unit test enablement was planned post FF as streach for Flamingo
16:28:13 gibi but if we block the nova-conductor refactor on it then I will at least make an arrangement to have test results
16:28:31 gibi I mean unit test results with image cache tests running in threading mode
16:28:42 gibi do you want me to do that?
16:29:47 bauzas I agree with the statement that I feel that the patches above n-api seem more important for now
16:29:58 opendevreview Max proposed openstack/nova master: db: add indexes for source/dest migrations https://review.opendev.org/c/openstack/nova/+/958556
16:30:36 gibi bauzas: so you say lets prioritize the unit test enablement over the nova-conductor work.
16:30:39 gibi ?
16:30:58 gibi (I have no problem with it if that is what the team wants)
16:31:00 bauzas for me, at least, I'd prefer reviewing those patches
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 ?

Earlier   Later