| *** __ministry is now known as Guest25005 | 02:05 | |
| opendevreview | Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578 | 02:41 |
|---|---|---|
| opendevreview | Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578 | 03:11 |
| gmaan | sean-k-mooney: ^^ updated service role change - https://review.opendev.org/q/topic:%22bp/policy-service-role-default%22+status:open | 03:12 |
| gmaan | sean-k-mooney: I updated the tempest tests also. it seems neutron, cinder (for server external event and volume swap) still needs to assign admin role also to service user because nova need to perform the background task like get server/volume of other project which service user do not have access too. basically service user will have: | 03:14 |
| gmaan | - service role: for nova to check the policy if request is from service or not. ( API policy will be default to 'role:service' only (admin also for this cycle) ) | 03:14 |
| gmaan | - admin role: to perform the actual operation | 03:14 |
| gmaan | i will check gate result if anything failing but for safer side I am testing cinder, neutron, ironic also depends-no on nova change | 03:15 |
| gmaan | complete set with testing changes are https://review.opendev.org/q/topic:%22bp/policy-service-role-default%22+status:open | 03:15 |
| *** __ministry is now known as Guest25014 | 05:44 | |
| opendevreview | Kamil Sambor proposed openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088 | 09:19 |
| ralonsoh | Hi folks, quick question, if you know how to do it and if it is possible. Can Nova serve the metadata compressed? Context: https://bugs.launchpad.net/neutron/+bug/2120723 | 09:43 |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Fix the help for hw:cpu_policy flavor extra spec https://review.opendev.org/c/openstack/nova/+/958524 | 09:47 |
| sean-k-mooney | ralonsoh: not that im aware of, althoguh technically if your runing the wsgi applcaition under apache or similar it can add compressions | 10:51 |
| sean-k-mooney | ralonsoh: we do not have code to compress it in nova itslef | 10:51 |
| sean-k-mooney | but apache or nginx coudl do it | 10:51 |
| sean-k-mooney | if it did that would be refected in headers in the reponce | 10:52 |
| sean-k-mooney | if they are going via a loadblancer like haproxy that could also do compression tecnially btu i dont think that would be typical. | 10:53 |
| sean-k-mooney | ralonsoh: my advice wodl be do not treat it as text but a binary string | 10:54 |
| ralonsoh | sean-k-mooney, yeah, the problem is the metadata proxy in neutron | 10:54 |
| ralonsoh | we are doing exactly that: treating the http content as text | 10:54 |
| elodilles | sean-k-mooney: i've looked at the watcher release patch and i have a question there: https://review.opendev.org/c/openstack/releases/+/958468 | 11:13 |
| sean-k-mooney | elodilles: replied its technically a bugfix bump not a patch bump but i can elevate it to a Feature/Minor bump if you like | 11:19 |
| sean-k-mooney | the external api behavior should remain effectivly the same | 11:19 |
| sean-k-mooney | i added translation code to make swap effectivly be migrate so even if you request swap it will now use migrate and be semanticly the same effect | 11:20 |
| sean-k-mooney | elodilles: but i dont have a stong prefernce here so if you would like me to respin i can do that quickly just let me know either way | 11:20 |
| elodilles | sean-k-mooney: neither have i :) | 11:21 |
| sean-k-mooney | shall i update to minor? it will take like 5 mins | 11:22 |
| sean-k-mooney | otherwise ill go back to code reivew :) | 11:22 |
| elodilles | sean-k-mooney: i've upgraded to +2 then, but feel free to edit if you changed your mind o:) | 11:24 |
| sean-k-mooney | we have elevated other secuirty patches to feature bumps in the past os for visiblity im torn. bugfix patches everyone shoudl basiclly take sometime folks are less inclined to take minor bumps but i still have the change open in emacs so let me quickly edit it and ill update teh commit message too | 11:27 |
| priteau | Hello. Sorry to bother you again, we're still looking for approval for these stable backports: https://review.opendev.org/c/openstack/nova/+/945098 and https://review.opendev.org/c/openstack/nova/+/945099 | 11:29 |
| sean-k-mooney | elodilles: updated | 11:33 |
| sean-k-mooney | priteau: sure no worries i keep opening those and not finsihing revieing them ill do it now | 11:33 |
| elodilles | sean-k-mooney: +2'd, thanks! | 11:37 |
| sean-k-mooney | priteau: elodilles i have +2w'd the 2024.2 version and +2'd the 2024.1 version of those so once the former merges elod can upgrade there +1 on the latter and merge them | 11:39 |
| elodilles | ACK, i'll take an eye on it | 11:42 |
| sean-k-mooney | general quetion for folks. how woudl people feel about have ing "meta traits" taht are reported if an only iff all the cpu feature flags for x86-64 version profile are met | 11:47 |
| sean-k-mooney | https://en.wikipedia.org/w/index.php?title=X86-64§ion=20#Microarchitecture_levels | 11:47 |
| sean-k-mooney | basiclly the libvirt driver would addtionally report x86-64-v2 if all of the cpu feature flags requried for that were actully supported | 11:48 |
| sean-k-mooney | same for v3 and v4 | 11:48 |
| sean-k-mooney | that would mean if you had a rhel 10 iamge for example that can only run on v3 you coudl do a singel required trait x86-64-v3 | 11:49 |
| sean-k-mooney | instead of listing all of the v3 ones indeviually | 11:49 |
| sean-k-mooney | you could go one step futher and supprot defining meta traits in placement directly so you would not need to report them but coudl request them and it do the translation internally | 11:51 |
| sean-k-mooney | that could be very useful eventually but i am not sure i want to go that far right now | 11:52 |
| sean-k-mooney | how that woudl work would be creatign a new api to define a meta traits as a union of other triaits (possible even a set of requried/forbiden triat instead of a plain union of required) and placement woudl just pre process the allocation candiate string and replace any meta taits with the expanded set | 11:53 |
| sean-k-mooney | that woudl allow admins to defien there own but im not sure we need that level of flexablity | 11:54 |
| opendevreview | Merged openstack/nova stable/2024.2: Reproduce bug/2098496 https://review.opendev.org/c/openstack/nova/+/945098 | 12:12 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Separate volume, snapshot and volume attachments https://review.opendev.org/c/openstack/nova/+/952347 | 12:55 |
| opendevreview | Stephen Finucane proposed openstack/nova master: tests: Use valid UUIDs for cinder resources https://review.opendev.org/c/openstack/nova/+/952935 | 12:55 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Only apply "soft" additionalProperties validation to requests https://review.opendev.org/c/openstack/nova/+/952936 | 12:55 |
| stephenfin | sean-k-mooney: Those functional tests are fixed now, if you're game to re-apply your +2/+W? ^ | 13:00 |
| sean-k-mooney | done ill let gmaan hit https://review.opendev.org/c/openstack/nova/+/952347/9 but the next 2-3? have +2w | 13:02 |
| opendevreview | Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584 | 13:02 |
| sean-k-mooney | as we dicussed offline once that batch is in we can see if you need to rebase the rest or if they will just apply | 13:03 |
| opendevreview | Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584 | 13:57 |
| opendevreview | Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584 | 14:12 |
| bauzas | dansmith: can you just +2/+W that very old Flamingo patch that modifies the support envelope for our non-SLURP release ? https://review.opendev.org/c/openstack/nova/+/944018 | 14:30 |
| bauzas | this is too way overdue | 14:30 |
| dansmith | bauzas: I thought we were sticking with two releases always to make sure we always support skip-level? | 14:32 |
| bauzas | nope, we always set the minimum object version to N-1 if we are on a non-SLURP as we don't support skip-level for ops | 14:33 |
| dansmith | ...but we run grenate-skip-level-always | 14:33 |
| dansmith | I'm not sure why that didn't fail though (logs are gone) | 14:33 |
| bauzas | indeed, but that's again not our support envelope | 14:33 |
| bauzas | skip-level changes the option and bypasses that value then | 14:33 |
| dansmith | does it? | 14:33 |
| bauzas | (IIRC) | 14:34 |
| bauzas | yeah, IIRC we have a flag that says "I gonna skip the min version" | 14:34 |
| bauzas | for something we called FFU way long before | 14:34 |
| bauzas | the beast is gone but the flag remains | 14:34 |
| dansmith | if so I don't know where that is | 14:34 |
| bauzas | https://review.opendev.org/c/openstack/nova/+/913890 was the one we merged for Dalmatian | 14:35 |
| bauzas | NOVA_ENABLE_UPGRADE_WORKAROUND is the tempest flag if I'm not mistaken | 14:36 |
| dansmith | yeah, I see, but .. I'm not sure that's right | 14:36 |
| bauzas | https://opendev.org/openstack/grenade/src/branch/master/projects/60_nova/upgrade.sh#L77 | 14:38 |
| dansmith | I'm not sure skip-level-always actually does a multinode and leaves a node behind.. from the code I don't see how this would not break a skip level | 14:38 |
| bauzas | that's the thing we did from Antelope and older | 14:38 |
| bauzas | skip-level was turning the object version check off | 14:38 |
| bauzas | but we always said that our support envelope was N-1 | 14:39 |
| bauzas | for non-SLURP | 14:39 |
| dansmith | okay, I see yeah | 14:39 |
| bauzas | I even wrote that big fat comment in the object | 14:39 |
| bauzas | some day around early october after we branch RC1, we would keep the value of that object | 14:40 |
| bauzas | as we would continue to support Epoxy | 14:40 |
| dansmith | yes there's a big comment, but it doesn't cover the skip-level detail | 14:40 |
| bauzas | even if master is Gazpatcho-based | 14:40 |
| dansmith | while I was grepping through the tree, my shell was reminding me that I have run some of the same greps in the last year, so clearly I was doing the same thing last time ;) | 14:41 |
| bauzas | I can add some extra paragraph that would mention that that value is not read by skip-level | 14:41 |
| bauzas | as skip-level turns on [workarounds]/disable_compute_service_check_for_ffu | 14:41 |
| bauzas | lemme then amend my patch and add that comment to prevent another brain cycle next time :) | 14:42 |
| dansmith | yeah just mentioning the config option might be enough | 14:43 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Update min support for Flamingo https://review.opendev.org/c/openstack/nova/+/944018 | 14:52 |
| bauzas | dansmith: can you just reapply your +W ? | 14:53 |
| dansmith | done | 14:54 |
| bauzas | thanks | 14:55 |
| dansmith | gibi: I don't have anything proposed but unmerged for precache | 15:00 |
| gibi | ack | 15:00 |
| gibi | I will test a bit manually the eventlet removal change then | 15:00 |
| dansmith | _probably_ because we can't externally validate it, we could only make sure it didn't fail the call or something | 15:01 |
| sean-k-mooney | i was talking to gmann about this at one point | 15:01 |
| gibi | dansmith: ahh good point. Maybe whitebox then... | 15:01 |
| sean-k-mooney | about maybe adding a whitebox test to ssh in and assert the base image is created after caching | 15:01 |
| dansmith | yeah | 15:01 |
| sean-k-mooney | i dont know if they wrote that test yest hwoever but let me look | 15:01 |
| gibi | I don't see anything in whitebox either | 15:02 |
| sean-k-mooney | no i don tthink they started on it | 15:03 |
| sean-k-mooney | we were chating about it in the context of dicussiong what ci coverage we had in general when they joined the team | 15:03 |
| gibi | OK. manual testing then... I anyhow wanted to test two different caching running in paralle | 15:03 |
| dansmith | that might be hard unless you have a large image or artificially slow it down | 15:04 |
| sean-k-mooney | it would be nice to add a test for it to whitebox eventually | 15:04 |
| gibi | sean-k-mooney: I agree | 15:04 |
| gibi | dansmith: yepp I will do one or the other :) | 15:04 |
| sean-k-mooney | so gmaan recently added a test for booting form an iso to validate that https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/955950/4/whitebox_tempest_plugin/api/compute/test_iso_image.py | 15:05 |
| sean-k-mooney | so we already have a custom image file in ci we could use | 15:05 |
| sean-k-mooney | i.e. we can create a new imag e in the test in clance using the iso | 15:06 |
| sean-k-mooney | and the pre cache that to an aggreate | 15:06 |
| gibi | cool | 15:10 |
| gmaan | gibi: sean-k-mooney this is where I added Core-14.0.iso image in job and devstack download it and tempest plugin can play with that image from file locattion - https://github.com/openstack/whitebox-tempest-plugin/blob/master/.zuul.yaml#L72C206-L72C219 | 15:11 |
| gibi | thanks | 15:13 |
| sean-k-mooney | we could also have used any of the sandard images like cirros but since whitebox now expect an iso at least to run that test we might as well use it esplciy since we are intenallysuing tiny core which as the name implies is small | 15:14 |
| sean-k-mooney | i want to revive the idea of running a subset of whitebox in nova's check jobs at somepoint by the way | 15:15 |
| gmaan | yeah, that is not too large but we can add larger image here | 15:15 |
| sean-k-mooney | we can skip all the ahrdware specfic stuff but obvioulsy but this and the iso but check woudl be nice to have | 15:15 |
| gmaan | only tricky part of ssh into server booted from iso image. But i do not think pre-cache image test need that | 15:15 |
| sean-k-mooney | we are also not doing that in whitebox today for the iso case | 15:16 |
| gmaan | sean-k-mooney: good idea, I can add that or maybe we can run a separate peroidic job as full whitebox plugin | 15:16 |
| gmaan | I mean running iso image test in nova | 15:16 |
| sean-k-mooney | i spoke to melwitt breifly about changing nova-ovs-hybird plug in to nova-alt-config adn having it test more things | 15:17 |
| sean-k-mooney | so rather then adding a new job or continuing to extend nova-next i woudl put it in that job | 15:17 |
| sean-k-mooney | we can chat about that in more detail after FF ro at teh ptg whenever we have tiem to plan that out | 15:18 |
| sean-k-mooney | but i was chatting to her about enableing nova on nfs and cinder nfs in that job | 15:18 |
| sean-k-mooney | so we have coverage of both goign forward | 15:18 |
| sean-k-mooney | so nova-alt-config woud test spice, ml2/ovs, nfs and whitebox things | 15:19 |
| sean-k-mooney | on debian 13 | 15:19 |
| sean-k-mooney | so it will also test python 3.13 | 15:20 |
| sean-k-mooney | that is how i woudl like to evolve that job in anyrate | 15:20 |
| gmaan | sure | 15:26 |
| sean-k-mooney | gmaan: when you have time would you mind reappoving https://review.opendev.org/c/openstack/nova/+/952347 | 15:32 |
| gmaan | sean-k-mooney: yeah, I opened it, will do after meeting | 15:32 |
| sean-k-mooney | ack thanks | 15:32 |
| Uggla | Nova meeting in ~30mn | 15:35 |
| gmaan | Uggla: openinfra board finance committee at same time. so I might not be or might be late in today meeting | 15:44 |
| Uggla | gmaan ok, just a question about https://review.opendev.org/c/openstack/nova/+/957578 do you think it is something that could land before FF ? | 15:46 |
| gmaan | Uggla: I hope so, we are very close to that. I am testing it (forgot to recheck my testing change yesterday). I think sean-k-mooney is planning to review it (once I ping that it is working) | 15:47 |
| Uggla | It will be great ! | 15:48 |
| opendevreview | Stephen Finucane proposed openstack/nova-specs master: Fix URL for v2.0 API deprecation spec https://review.opendev.org/c/openstack/nova-specs/+/958552 | 15:48 |
| jssfr | Uggla, can I queue up https://review.opendev.org/c/openstack/nova/+/955657 and https://review.opendev.org/c/openstack/nova/+/621646 for the "further discussion" section? | 15:53 |
| Uggla | jssfr, yes I think so. | 15:54 |
| jssfr | In case I don't make it (it's been a busy day... and I might get pulled away): the vTPM patch has been updated and is awaiting review. Would be nice to get it into 2025.2. | 15:54 |
| jssfr | the UEFI patch has *not* been updated, but we'd like to hear whether it's realistic to get it into 2025.2 *if* we were to update it this week and if so, until when we would have to be done. | 15:54 |
| Uggla | jssfr, I think it is a bug, so there is less constraints, bugs are not fully concerned by FF. | 15:55 |
| jssfr | oh, that's good to know | 15:56 |
| Uggla | #startmeeting nova | 16:00 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| elodilles | o/ | 16:00 |
| dansmith | o/ | 16:00 |
| Uggla | Hello everyone | 16:00 |
| gibi | o/ | 16:02 |
| Uggla | Let's start. | 16:02 |
| Uggla | #topic Bugs (stuck/critical) | 16:02 |
| Uggla | #info No Critical bug | 16:02 |
| Uggla | #topic Gate status | 16:02 |
| Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:02 |
| Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:03 |
| tkajinam | o/ | 16:03 |
| 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 |
| Uggla | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:03 |
| Uggla | #info Please try to provide a meaningful comment when you recheck | 16:03 |
| bauzas | o/ | 16:03 |
| Uggla | skipping next point as gmaan, is in another meeting. | 16:04 |
| Uggla | topic Release Planning | 16:04 |
| Uggla | #link https://releases.openstack.org/flamingo/schedule.html | 16:04 |
| Uggla | #info Nova deadlines are set in the above schedule | 16:04 |
| Uggla | #info Feature freeze is Thursday. | 16:04 |
| Uggla | #topic Review priorities | 16:05 |
| Uggla | #link https://etherpad.opendev.org/p/nova-2025.2-status | 16:05 |
| 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 |
| Uggla | First I need to thank bauzas, who helped me to better highlight status in the board and sync correctly within launchpad. | 16:05 |
| bauzas | well, I should have given you some help way before | 16:06 |
| Uggla | gibi, I think so. I don't think exception will be needed but we might discuss it here. | 16:07 |
| Uggla | Before that here are the review priorities we identified: | 16:07 |
| Uggla | #link Amd Sev serie (tkajinam) need review https://review.opendev.org/q/topic:%22bp/amd-sev-es-libvirt-support%22 | 16:07 |
| Uggla | #link https://blueprints.launchpad.net/nova/+spec/copy-applied-provider-yaml https://review.opendev.org/c/openstack/nova/+/957578 | 16:07 |
| Uggla | #link https://blueprints.launchpad.net/nova/+spec/libvirt-migrate-parallel https://review.opendev.org/c/openstack/nova/+/950667 | 16:08 |
| 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:08 |
| Uggla | I discussed latest one with gmaan and that might land if we review it. (only one patch) | 16:09 |
| Uggla | bauzas and I are currently reviewing Amd sev series. | 16:10 |
| sean-k-mooney | o/ | 16:10 |
| gibi | Uggla: I'm currently try to squeez in https://review.opendev.org/c/openstack/nova/+/957088 before FF | 16:11 |
| gibi | the rest of the eventlet series can wait post FF / G | 16:11 |
| bauzas | my only concern is that AMD SEV-ES series requires a reshape | 16:11 |
| Uggla | gibi, thanks that was one of the question I had. | 16:12 |
| dansmith | gibi: you said you were fine with the content on that one, but...no unit tests? | 16:12 |
| bauzas | this requires a lot of caution | 16:12 |
| dansmith | are those coming? | 16:12 |
| sean-k-mooney | Uggla: techihnaly teh parla clodu migration chnag eis for 2026.1 | 16:12 |
| bauzas | the what ? | 16:12 |
| sean-k-mooney | or did we approve it late for this cycle | 16:12 |
| gibi | dansmith: it is a refactor like the scatter gather change | 16:12 |
| gibi | dansmith: I don't see what extra unit test we need | 16:13 |
| bauzas | well, yes and no | 16:14 |
| 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 |
| bauzas | there is a refactor but there is also a slight behavioral change | 16:14 |
| dansmith | the lock obviously isn't verified, but if it's being run over then maybe that's okay | 16:15 |
| 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 |
| gibi | I don't see any other change in logic | 16:17 |
| 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:18 |
| gibi | invasive? you mean a lock? | 16:19 |
| gibi | I'm confused | 16:19 |
| 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:19 |
| gibi | as it proves no behavior change happened | 16:20 |
| 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 |
| sean-k-mooney | so it would be nice to have the zuul change to enable it in the condutore in the patch | 16:21 |
| bauzas | gibi: I agree with the fact that until some env var is set, nothing changes | 16:21 |
| sean-k-mooney | but i dont consider that an invasive change either for what its worth | 16:22 |
| 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 |
| bauzas | but yeah, I'd have appreciated some guideline to temper my guts | 16:22 |
| sean-k-mooney | its adding a lock that shoudl techenically have been there even under eventlet + swapting the executor we use | 16:22 |
| 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:22 |
| dansmith | but that's fine | 16:23 |
| gibi | dansmith: I will check my unit test enalbing series if it enables the related tests already... | 16:23 |
| gibi | with threading in a separate tox target | 16:23 |
| sean-k-mooney | what was that job called by the way | 16:24 |
| sean-k-mooney | i tough we already enabled that in ci | 16:24 |
| sean-k-mooney | is that still pending? | 16:24 |
| gibi | nova-tox-py312-threading | 16:24 |
| gibi | it is pending | 16:25 |
| gibi | https://review.opendev.org/c/openstack/nova/+/955791/9 | 16:25 |
| sean-k-mooney | ah ok | 16:25 |
| sean-k-mooney | sorry i tought that was earlier in the series | 16:25 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/953475/20 that one right | 16:25 |
| 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:25 |
| sean-k-mooney | there are a number of the ci/testing changes that woudl be nice to also land | 16:26 |
| 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 |
| sean-k-mooney | but i wonder if we woudl be oke with some of those happening post FF | 16:26 |
| dansmith | gibi: ack | 16:27 |
| 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 |
| 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 |
| gibi | yeah the unit test enablement was planned post FF as streach for Flamingo | 16:27 |
| 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 |
| gibi | I mean unit test results with image cache tests running in threading mode | 16:28 |
| gibi | do you want me to do that? | 16:28 |
| bauzas | I agree with the statement that I feel that the patches above n-api seem more important for now | 16:29 |
| opendevreview | Max proposed openstack/nova master: db: add indexes for source/dest migrations https://review.opendev.org/c/openstack/nova/+/958556 | 16:29 |
| gibi | bauzas: so you say lets prioritize the unit test enablement over the nova-conductor work. | 16:30 |
| gibi | ? | 16:30 |
| gibi | (I have no problem with it if that is what the team wants) | 16:30 |
| bauzas | for me, at least, I'd prefer reviewing those patches | 16:31 |
| sean-k-mooney | i was going to suggest rebasign the 6 packages on top of the conductor one | 16:31 |
| bauzas | and I think those would be more beneficial for the rest of the work we have to do | 16:31 |
| bauzas | sean-k-mooney: you mean, on the bottom ? | 16:32 |
| sean-k-mooney | no | 16:32 |
| gibi | sean-k-mooney: yeah that what I meant by arranging to get test results | 16:32 |
| sean-k-mooney | because i disagree that havign the ablity to run the condcutor in treading mdoe is less valuable | 16:32 |
| gibi | sambork: Are you around? ^^ :) | 16:33 |
| sean-k-mooney | if we have the conductor patch we can test it and ask operator to test it and report bugs | 16:33 |
| bauzas | if wre're not able to run it in CI, what's the benefit ? | 16:33 |
| sean-k-mooney | we can trivially | 16:33 |
| sean-k-mooney | its liktrally a 1 line change to the zuul job | 16:33 |
| sean-k-mooney | to set the var in devstack to enabel threading mode | 16:33 |
| bauzas | but we won't execute that code, right? | 16:33 |
| gibi | sean-k-mooney: I think what bauzas imply is that we don't have tempest coverage for the changed code path | 16:33 |
| sean-k-mooney | ok that should nto block the code change | 16:34 |
| bauzas | I mean, the zuul config change will be meaningless | 16:34 |
| bauzas | if we don't have zuul jobs that call image caching | 16:34 |
| sean-k-mooney | its wont be it makes sure everythign else in the conductor works | 16:34 |
| sean-k-mooney | i.e. that we are not implcitly relying on eventlet indrectly | 16:34 |
| bauzas | that is a good point | 16:34 |
| bauzas | we could have missed other eventlet dependencies | 16:35 |
| bauzas | I then agree, | 16:35 |
| 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 |
| sean-k-mooney | my suggesting is for gibi to rebase them so we get more results today/tomorrow | 16:35 |
| bauzas | agreed, I like that approach | 16:36 |
| sean-k-mooney | and then we can decied if we are comfrotabel with merging the conductor changes | 16:36 |
| gibi | I will do the rebase today to get unit test results with threadin on image cache | 16:36 |
| bauzas | thanks gibi | 16:36 |
| gibi | sambork: ^^ FYI | 16:36 |
| sean-k-mooney | gibi: can we add the devstack job change too if you or sambork have time | 16:36 |
| gibi | I will do local testing of the lock explicitly | 16:36 |
| gibi | sean-k-mooney: I will do so | 16:36 |
| sean-k-mooney | +1 | 16:36 |
| gibi | I have nothing further | 16:37 |
| 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 |
| bauzas | about the other things to review, I want to speak about SEV-ES | 16:38 |
| bauzas | but tkajinam is not here I guess (and hope) | 16:38 |
| tkajinam | I am | 16:38 |
| bauzas | wow | 16:38 |
| bauzas | okayu | 16:39 |
| tkajinam | :-) | 16:39 |
| sean-k-mooney | stephenfin: and i both were interested in the sev one as well | 16:39 |
| sean-k-mooney | or at least started looking at ti | 16:39 |
| dansmith | Uggla: land...in the next two days? | 16:39 |
| sean-k-mooney | so i think taht woudl be good to try and land | 16:39 |
| bauzas | my concern is that we're on a non-SLURP release | 16:40 |
| sean-k-mooney | but the main problem with that serise is reviewing the reshape | 16:40 |
| 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 |
| Uggla | dansmith yes if possible. | 16:40 |
| Uggla | or at least try. | 16:40 |
| tkajinam | bauzas, yes | 16:41 |
| dansmith | that seems like a big ask to me, | 16:41 |
| 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 |
| dansmith | but I'm not really positioned to review a reshape | 16:41 |
| 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 |
| bauzas | I feel reasonable being able to review a reshape since I wrote two of them | 16:42 |
| 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 |
| bauzas | but that's a very old knowledge part of myself I need to go with | 16:42 |
| sean-k-mooney | bauzas: that would help because the rest of the serise is much more straght forward | 16:42 |
| bauzas | sean-k-mooney: I can help with providing pointers to how the reshape mechanism works | 16:43 |
| bauzas | from the very first glance I made on tkajinam's series, he perfectly managed it | 16:43 |
| bauzas | I mean, he's triggerring the signal, and then using the signal to reshape | 16:43 |
| sean-k-mooney | well thats encuraging at least. | 16:43 |
| 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:43 |
| bauzas | tkajinam: do you have any excerpts of a real environment upgrade scenario that you tested locally ? | 16:44 |
| bauzas | I mean, pastebins | 16:44 |
| bauzas | that would ease the review | 16:44 |
| 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 |
| sean-k-mooney | to see it properly migrate the exsting allcoations | 16:45 |
| bauzas | that yes | 16:45 |
| bauzas | that's how I tested VGPU reshapes | 16:45 |
| 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:46 |
| bauzas | tkajinam: but I assume you tested such upgrade scenario, right? | 16:47 |
| 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 |
| bauzas | like, you had an env, you patched it, you saw the allocations moved | 16:47 |
| tkajinam | yes, when I wrote the series initially. | 16:48 |
| bauzas | excellent | 16:48 |
| bauzas | and yeah, functional tests can prove it works | 16:48 |
| bauzas | so if you already wrote them (I haven't reviewed them yet), that's excellent | 16:48 |
| bauzas | tkajinam: I assume you found how to do it using the existing reshape methods? | 16:48 |
| tkajinam | yeah | 16:49 |
| tkajinam | https://review.opendev.org/c/openstack/nova/+/921814/32/nova/tests/functional/libvirt/test_reshape.py#233 | 16:49 |
| bauzas | perfecty | 16:49 |
| tkajinam | I followed the existing rehape test for mdev, IIRC | 16:49 |
| bauzas | OK, I'll defineitely commit myself to the review then | 16:49 |
| Uggla | ok shall we move on ? | 16:51 |
| bauzas | yup, we'll see what we can do for the other bits | 16:51 |
| bauzas | like every cycle | 16:52 |
| Uggla | sure, what we have today is already cool. | 16:53 |
| Uggla | so moving on. | 16:53 |
| Uggla | #topic OpenAPI | 16:53 |
| Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | 16:53 |
| Uggla | #info still 32 remaining atm. | 16:53 |
| Uggla | so this will probably not fully land in this cycle, but we made good progress. | 16:54 |
| Uggla | #topic Stable Branches | 16:54 |
| Uggla | elodilles, please go ahead. | 16:54 |
| elodilles | #info stable branches (stable/2025.1 and stable/2024.*) seem to be in OK state | 16:55 |
| 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 |
| elodilles | with the sec related bug fix from last week | 16:55 |
| elodilles | and that's all from me for now, back to you Uggla | 16:55 |
| Uggla | thx elodilles | 16:55 |
| elodilles | np | 16:55 |
| Uggla | skipping next point due to fwiesel pto's | 16:56 |
| Uggla | I also guess we can skip gibi's point as I think he already covered previously. | 16:57 |
| gibi | yepp nothing further for FF. I have things for post FF but we can disucss that next week | 16:57 |
| 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:58 |
| jssfr | did the UEFI NVRAM preservation thing also count as bugfix? | 16:59 |
| sean-k-mooney | yes | 16:59 |
| jssfr | okay, thanks | 16:59 |
| 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 |
| jssfr | (even if not, it looks like y'all are busy enough getting all the other features over the line) | 16:59 |
| jssfr | thanks, then we can certainly defer to next week from my side | 16:59 |
| Uggla | jssfr thx. | 17:00 |
| Uggla | So I'm gonna close, thanks all. | 17:00 |
| Uggla | #endmeeting | 17:00 |
| 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 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-26-16.00.html | 17:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-26-16.00.txt | 17:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-26-16.00.log.html | 17:00 |
| 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:00 |
| sean-k-mooney | im also quitely hopeful we could land gmaan's service role change | 17:01 |
| sean-k-mooney | i loooked at it today and after some back and forth on scope it looks good | 17:01 |
| Uggla | yep me too, at least gmaan was quite confident about it | 17:01 |
| bauzas | tkajinam: still here ? | 17:01 |
| tkajinam | yes | 17:01 |
| 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 |
| Uggla | sean-k-mooney, it would be cool for the openapi too, even probably less a priority | 17:02 |
| 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:02 |
| 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 |
| 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 |
| 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:03 |
| Uggla | sean-k-mooney +1 | 17:04 |
| bauzas | tkajinam: nothing should break, since old computes fulfilling AMD SEV requests would continue to be able to allocate them | 17:04 |
| bauzas | new computes would be able to do that as well | 17:04 |
| 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 |
| bauzas | yup | 17:05 |
| sean-k-mooney | we allow requests in the root group to be fullfiled by any RP in the tree right | 17:06 |
| tkajinam | bauzas, yeah I understand that point. | 17:07 |
| 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 |
| bauzas | I hope, but | 17:07 |
| sean-k-mooney | i know we talked about that before i dont recall what it does today | 17:07 |
| sean-k-mooney | if not we woudl ahve ot transfrom the SEV request ito a sepreate group | 17:07 |
| sean-k-mooney | to suppro the mixed case | 17:08 |
| 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 |
| sean-k-mooney | but i dont think that is required. | 17:08 |
| 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 |
| sean-k-mooney | this is something that an upgraded schduler is capable of doing however since we dont sue resouce: directly | 17:09 |
| bauzas | tkajinam: do you think you could write such functional test quickly? | 17:09 |
| bauzas | I just want to prevent any placement behavioural change I could have missed :) | 17:10 |
| bauzas | and we would also ensure we don't regress, particularly if someone wants to change how placement is fulfilling requests | 17:11 |
| tkajinam | bauzas, the current functional tests covers instance creation before reshape and creation after reshape using a single RP, so that proves sev instance can be scheduled to old compute node and also new compute node | 17:13 |
| bauzas | it doesn't prove that instance creation can be fulfiled on a mixed env, that's the point | 17:13 |
| bauzas | oh, I see what you mean | 17:14 |
| tkajinam | I can create a scenario with two RPs, but do you expect that we create two servers in that case but I'm not sure if I can enforce these two scheduled to two different (old/new) compute nodes | 17:14 |
| bauzas | tkajinam: that is doable, we have other functional tests where we fake the targets | 17:15 |
| bauzas | but anyway, I see your point | 17:15 |
| bauzas | shall work anyway, so here I think a follow-up patch is only needed | 17:16 |
| tkajinam | ok | 17:17 |
| tkajinam | I'll push follow-up to run similar scenario with two mixed nodes, but I believe that compatibility scenario is already covered by the existing scenario using one node. | 17:18 |
| bauzas | thanks, appreciated | 17:19 |
| opendevreview | Merged openstack/nova stable/2024.2: Ignore metadata tags in pci/stats _find_pool logic https://review.opendev.org/c/openstack/nova/+/945099 | 17:41 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Add functional test scenario for mixed SEV RPs https://review.opendev.org/c/openstack/nova/+/958562 | 17:53 |
| tkajinam | bauzas, I hope this matches your expectation but lmk if you want additional steps (like creating servers before reshape) | 17:53 |
| bauzas | tkajinam: <3 | 17:54 |
| tkajinam | I put it on the last one to avoid mass rebase but I can change the order... I noticed that I didn't add that comment to the initial functional test scenario so I'll move that part to the reshape patch if I have to respin | 17:54 |
| bauzas | tkajinam: putting it on top is fine by me | 17:54 |
| bauzas | anyway, I just need to review your series for now | 17:55 |
| tkajinam | (the comment I'm referring to is https://review.opendev.org/c/openstack/nova/+/958562/1/nova/tests/functional/libvirt/test_reshape.py#259 ) | 17:55 |
| tkajinam | bauzas, thanks !! | 17:55 |
| bauzas | tkajinam: one thing, we keep providing capabilities as traits to the root RP, not the children ones, right? | 17:59 |
| bauzas | oh nevermind, no | 17:59 |
| tkajinam | bauzas, no we have to migrate the trait to its children, so that we can have SEV children tree as well as SEV-ES children tree | 18:01 |
| tkajinam | MEM_ENCRYPTION_CONTEXT for SEV-ES can't be used for SEV so we have to define the trait at children layer | 18:01 |
| bauzas | yup, and your functional traits test covers that, so I understood my mistake | 18:02 |
| tkajinam | :-) | 18:05 |
| tkajinam | I'm leaving soon but will check the irc logs as well as any review comments tomorrow | 18:05 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Ask for pre-prod testing for native threading https://review.opendev.org/c/openstack/nova/+/957424 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Allow to start unit test without eventlet https://review.opendev.org/c/openstack/nova/+/953436 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Run unit test with threading mode https://review.opendev.org/c/openstack/nova/+/953475 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [test]RPC using threading or eventlet selectively https://review.opendev.org/c/openstack/nova/+/953815 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [CI]Make nova-tox-py312-threading voting https://review.opendev.org/c/openstack/nova/+/955791 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Do not yield in threading mode https://review.opendev.org/c/openstack/nova/+/950994 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Make RBD Tpool usage conditional https://review.opendev.org/c/openstack/nova/+/956089 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Make libvirt Tpool proxying conditional https://review.opendev.org/c/openstack/nova/+/956090 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Fix ProviderTree copying with threading Lock https://review.opendev.org/c/openstack/nova/+/956091 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [test]Further categorization of disabled unit tests https://review.opendev.org/c/openstack/nova/+/956092 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [vncproxy]Handle ssl.wrap_socket removal in py312 https://review.opendev.org/c/openstack/nova/+/955915 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Warn on long task wait time for executor https://review.opendev.org/c/openstack/nova/+/952666 | 19:14 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-conductor in native threading mode https://review.opendev.org/c/openstack/nova/+/958575 | 19:14 |
| gibi | I rearranged the series ^^ so we will get unit test run with native threading with the conductor change | 19:17 |
| sean-k-mooney | ack ill start reviewign those now | 19:17 |
| gibi | locally py312-threading passing for me with the conductor changes. I will do the manual testing in devstack tomorrow | 19:18 |
| sean-k-mooney | gibi: bar the conductor change which i need to review im +2 on all of those up until "Do not yield in threading mode" | 19:31 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!