16:01:41 <Uggla> #startmeeting nova 16:01:41 <opendevmeet> Meeting started Tue May 20 16:01:41 2025 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:41 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:41 <opendevmeet> The meeting name has been set to 'nova' 16:01:47 <Uggla> Hello everyone 16:02:20 <gibi> o/ 16:02:33 <dansmith> o/ 16:02:38 <gmaan> o/ 16:02:52 <masahito> o/ 16:02:54 <bauzas> o/ 16:02:54 <fwiesel> o/ 16:03:46 <Uggla> #topic Bugs (stuck/critical) 16:04:06 <elodilles> o/ 16:04:07 <Uggla> #info No Critical bug 16:04:16 <Uggla> #info https://bugs.launchpad.net/nova/+bug/2110545 from last week. 16:04:24 <Uggla> #info We merged https://review.opendev.org/c/openstack/nova/+/949622 proposal to skip the the problematic job. 16:04:39 <gibi> we probably need to decrease the severity of it now that it is not blocking the gate 16:04:57 <gibi> moved it to High now 16:05:02 <Uggla> ok I was about to ask about it 16:05:09 <Uggla> https://review.opendev.org/c/openstack/nova/+/922140 bauzas working on a patch to enable nova-next. 16:05:39 <Uggla> bauzas, am i correct with ^ ? 16:05:40 <bauzas> I still need to understand why compute1 doesn't like me 16:05:54 <bauzas> but let's not discuss my problem now 16:06:25 <bauzas> I would appreciate some devstack/zuul expert to help me finding the cause that's it 16:07:10 <Uggla> cool, it is on a good path to be resolved. 16:07:13 <bauzas> tldr: multi-node's compute1 apparently doesn't get the right repo branch 16:07:49 <Uggla> bauzas, anything else you want to add ? 16:08:28 <Uggla> seems not so moving on 16:08:33 <Uggla> #topic Gate status 16:08:42 <Uggla> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16:08:47 <Uggla> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal 16:08:55 <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:09:02 <Uggla> #info Please look at the gate failures and file a bug report with the gate-failure tag. 16:09:05 <bauzas> Uggla: sorry, nope 16:09:08 <Uggla> #info Please try to provide meaningful comment when you recheck 16:09:49 <Uggla> #topic tempest-with-latest-microversion job status 16:10:00 <Uggla> #link https://zuul.opendev.org/t/openstack/builds?job_name=tempest-with-latest-microversion&skip=0 16:10:16 <Uggla> gmaan, do you want to say something about it ? 16:11:00 <gmaan> one update, keypair test passing. I was working for server tags tests which need more update as its schema missing since starting 16:11:21 <gmaan> it in-progress https://review.opendev.org/c/openstack/tempest/+/949682 16:11:26 <gmaan> sorry instance action 16:11:32 <gmaan> that is all for this week 16:11:41 <Uggla> gmaan, thx 16:11:53 <Uggla> #topic Release Planning 16:11:58 <Uggla> #link https://releases.openstack.org/flamingo/schedule.html 16:12:05 <Uggla> #info Nova deadlines are set in the above schedule 16:12:15 <Uggla> #info Only 2 weeks before Nova Spec Soft Freeze, do not forget to submit your specs. 16:12:31 <Uggla> #topic Review priorities 16:12:36 <Uggla> #link https://etherpad.opendev.org/p/nova-2025.2-status 16:12:49 <Uggla> FYI I have requested #openstack-nova channel ops for sean-k-mooney, bauzas, gibi, dansmith, melwitt, Uggla 16:13:34 <gibi> thanks1 16:13:38 <sean-k-mooney> ack. i suspect we will very rarely need to use that 16:13:53 <sean-k-mooney> but it would have been nice to have been able to fix the topic before 16:14:31 <Uggla> I think we should start reviewing and approving specs. 16:14:31 <gibi> yeah it is only for the topic 16:14:51 <bauzas> noted 16:15:08 <Uggla> Let's start with : https://review.opendev.org/c/openstack/nova-specs/+/945549, https://review.opendev.org/c/openstack/nova-specs/+/947542, https://review.opendev.org/c/openstack/nova-specs/+/949504 16:15:31 <Uggla> The 2 last ones are reproposal, so it will be glad to approved them. 16:16:07 <Uggla> The first one is about cloud hypervisor. It was reviewed by Dan 16:16:29 <Uggla> But that would cool to have feedbacks from another core. 16:16:46 <dansmith> fwiesel: I reviewed that spec, but I'm not going to approve it, FWIW 16:16:51 <sean-k-mooney> i pushed my pending comments... 16:16:55 <dansmith> oops, sorry Uggla: ^ 16:17:07 <sean-k-mooney> i really need to stop forgetign to do that 16:17:26 <dansmith> I don't have time to really review the implementation in detail and so I don't want to be the +2 on the spec 16:17:43 <sean-k-mooney> if i recall correctly they have set up a ppa to rpovide the libvirt integration. 16:17:55 <Uggla> cool, the author pinged me and was worried, so that's cool if he has new feedback. 16:17:58 <sean-k-mooney> that solves part of the how can we test this in ci aspect 16:19:07 <sean-k-mooney> i think were we are right now is 16:19:16 <sean-k-mooney> without seeign the code and some work towards the integration 16:19:16 <Uggla> Also FYI I think the document is up2date regarding the current spec status, so feel free to pick specs for review. 16:19:28 <sean-k-mooney> we cant really make much more of a judvemnt call on the desgin 16:19:54 <masahito> hi, we started to update the supporting trait tracking by the provider.yaml feature nova-spec with PoC. https://review.opendev.org/c/openstack/nova-specs/+/937587 16:20:00 <sean-k-mooney> so we coudl approve the spec btu we cant really commit to landign the feature until they start building it out and imporantly the devstack supprot and ci for the same 16:21:22 <Uggla> sean-k-mooney, sure I think approving the spec is good. So author can "check" that box. 16:21:25 <sean-k-mooney> Uggla: the vtpm spec is on my radar to review this week. if the cinder one actully makes progress i dont have issues with that either but i have not reviewd it since last cycle. im not sure if we really want to go into details on those in real time 16:21:50 <gibi> is it a general rule that we should not +2 a spec if we are not commiting to review the impl? 16:22:07 * gibi trying to figure out how to vote 16:22:12 <sean-k-mooney> in the past no. 16:22:12 <dansmith> sean-k-mooney: agreed, I think we need to see a little sniff of the implementation in CI 16:22:31 <dansmith> gibi: not a hard rule, I just think for something like this I'm going to avoid putting my name on such an effort 16:22:39 <sean-k-mooney> but there is at least some expecation i guess that if you do +2 and the authour has questions you will at least try to guide them 16:22:59 <gibi> dansmith: ack 16:23:23 <sean-k-mooney> dansmith: i thinik if you know you wont have time then signaling that is also valuable 16:23:28 <gibi> sean-k-mooney: yeah by voting on the spec I agree I will be around to answer questions about the spec 16:25:09 <Uggla> Something to add ? 16:25:36 <sean-k-mooney> i think its good to call out the spec that are ready for review but i think we need to actully do the review async 16:25:59 <sean-k-mooney> so unless you have specific question i would suggest we move on and if we want to have a spec review day 16:26:28 <gibi> +1 16:26:32 <sean-k-mooney> we can do that but do that at/around the soft spec freeeze in june 16:26:45 <Uggla> sure this topic is just to highlight that specs are waiting and that we should start to review them not to be overwhelmed. 16:27:09 <sean-k-mooney> masahito: your sepc also has a poc implemantion if i recall correct 16:27:21 <sean-k-mooney> i belive gibi has alrady started to look at it too 16:27:24 <masahito> yup. 16:27:40 <masahito> is it okay to add it into the priority? 16:27:41 <sean-k-mooney> masahito: since you are here did you have any questions for us that you wanted input on 16:28:03 <sean-k-mooney> you can certenlly put it in the etherpad as ready for review if you think it is 16:28:05 <gibi> sean-k-mooney: yeah I looked at the PoC and I liked what I saw 16:28:25 <masahito> nothing now. i think the spec and poc need first review round now. 16:28:58 <sean-k-mooney> gibi: ack i opened it but didnt get to read it yet. masahito: ack 16:29:21 <Uggla> and so moving on. 16:29:23 <Uggla> #topic OpenAPI 16:29:30 <Uggla> #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned 16:29:35 <sean-k-mooney> masahito: please add it here https://etherpad.opendev.org/p/nova-2025.2-status#L34 16:29:40 <Uggla> 21 patches remaining. 16:30:04 <sean-k-mooney> actully slightly more 16:30:19 <sean-k-mooney> stephen as a branch on his github fork with all of them 16:30:42 <sean-k-mooney> but is propsoing them in batches. i was intended to review them today but didnt get to it so i will be reviewign them tomrrow 16:31:13 <masahito> sean-k-mooney: got it. thanks 16:31:16 <sean-k-mooney> im hoping gmaan or other will also have time in the next week or two to reviwe some of them 16:31:17 <Uggla> This topic is to follow progress on openapi. Because we said in PTG we would try to close it. 16:31:40 <gmaan> yeah, I will try if I can do during end of this week otherwise next week sometime 16:32:16 <Uggla> I have reviewed 2 of them. 16:32:52 <gmaan> I would not be able to review all of them together as it exhaust eyes checking all fields for many APIs :) but I will target some set 16:33:18 <Uggla> gmaan, I expect to progress of them week after week. 16:33:28 <sean-k-mooney> ya i can ususlly do 5-10 over the course of an hour or two and then i need to clear my mind 16:33:43 <sean-k-mooney> they are not hard persay but its hard to maintain concentration on them for long periods of time 16:33:59 <gmaan> yeah 16:34:33 <Uggla> yep my idea is to do a first pass on them and then if gmaan and sean-k-mooney you can review and merge that would be great. 16:35:25 <Uggla> any as time is flying, I'd like to move on the next topic. 16:35:33 <Uggla> #topic Stable Branches 16:35:43 <Uggla> elodilles, the floor is yours. 16:35:59 <elodilles> ack, thanks, not so much things this time 16:36:06 <elodilles> #info stable branches (stable/2025.1 and stable/2024.*) seem to be in OK state 16:36:11 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci 16:36:17 <elodilles> that's all from me 16:36:27 <elodilles> Uggla: back to you 16:36:37 <Uggla> thx elodilles 16:36:52 <elodilles> np 16:37:10 <Uggla> #topic vmwareapi 3rd-party CI efforts Highlights 16:37:23 <Uggla> fwiesel, anything to say ? 16:37:25 <fwiesel> Hi, no updates from my side. 16:37:35 <Uggla> ok 16:37:44 <Uggla> #topic Gibi's news about eventlet removal. 16:37:50 <Uggla> #link Series: https://gibizer.github.io/categories/eventlet/ 16:38:32 <Uggla> gibi, do you want to say something ? I think you are chasing for reviews. 16:38:45 <gibi> yepp 16:38:56 <gibi> the nova-scheduler series is ready for core review 16:39:10 <gibi> (I've added it to the status etherpad as well) 16:39:28 <gibi> the series starts here https://review.opendev.org/c/openstack/nova/+/947966 16:39:56 <gibi> the first 11 patches are ready to go, the last two depends on oslo.service to land and release the threading backend support 16:40:26 <gibi> that is it 16:40:56 <Uggla> cool thx gibi 16:41:05 <Uggla> #topic Open discussion 16:41:19 <Uggla> I can see topic on the agenda. 16:41:27 <Uggla> s/can/can't/ 16:42:01 <Uggla> so unless if we have points, maybe we can try to triage bugs. 16:43:20 <Uggla> #topic Bug scrubbing 16:43:27 <Uggla> #link: https://etherpad.opendev.org/p/nova-bug-selection-for-triaging#L4 16:44:01 <Uggla> First one : https://bugs.launchpad.net/nova/+bug/2110222 16:45:07 <Uggla> Nova server image uploaded to S3 uses singlepart instead of multipart upload 16:45:26 <gibi> that feels like a feature request 16:45:37 <Uggla> yep I was about to say the same. 16:46:34 <Uggla> it is more an optimization request. 16:47:11 <Uggla> So I could probably set the bug to invalid and ask for a blueprint. 16:47:13 <gibi> it is a small feature even a specless one if we can assume that we can pass the size to the glance client at uploat 16:48:28 <Uggla> ok I'll do that for this one. 16:48:37 <Uggla> Next one: https://bugs.launchpad.net/nova/+bug/2109727 - removing an host from an aggregate should be accepted even if the host no longer exists 16:48:54 <Uggla> I think it is a valid one as opened by Sylvain 16:50:09 <Uggla> bauzas, ^ 16:51:11 <gibi> I hope bauzas could push a functional reproducer for that 16:51:41 <bauzas> sorry was taking a break 16:52:02 <bauzas> not sure if I have time for the reproducer but I can try 16:52:39 <sean-k-mooney> bauzas: i guess that only matteres if your going to work on the bug 16:52:40 <Uggla> bauzas, at least this is something valid. 16:52:49 <sean-k-mooney> if not then the peroson who picks it up can 16:54:08 <Uggla> So I'll move the bug to valid. 16:54:16 <Uggla> Next one : https://bugs.launchpad.net/nova/+bug/2108974 - Keypairs lost during cross-cell resize in instance_extra 16:54:26 <opendevreview> Merged openstack/nova master: Revert "Support glance's new location API" https://review.opendev.org/c/openstack/nova/+/950336 16:55:42 <gibi> it has reproducer steps so somebody should run them and if reproducible mark it valid 16:56:29 <Uggla> Is resizing cross-cell supported ? 16:56:53 <dansmith> yeah 16:57:06 <dansmith> it uses shelve on the backend 16:57:22 <dansmith> and it has to copy between databases, so it might be missing something 16:58:46 <gibi> The config drive associated with the server, if there is one, will be re-generated on the destination host in the target cell. Therefore if the server was created with personality files they will be lost. However, this is no worse than evacuating a server that had a config drive when the source and destination compute host are not on shared storage or when shelve offloading and unshelving a server 16:58:52 <gibi> with a config drive. If necessary, the resized server can be rebuilt to regain the personality files. 16:59:07 <gibi> so maybe such config drive regen is the problem 16:59:25 <gibi> (the above is from https://docs.openstack.org/nova/latest/admin/configuration/cross-cell-resize.html#limitations ) 16:59:59 <dansmith> ah yep 17:01:04 <gibi> the bug says it is lost form metadata response as well 17:01:29 <Uggla> yep I understand it is not only config drive. 17:01:49 <gibi> and it also points to `select keypairs from dst_cell.instance_extra ` I did not know we have a copy of a keypair there 17:02:01 <gibi> but it says it is in the source cell 17:02:09 <gibi> so that is probably not copied to the dest cell DB 17:02:16 <gibi> I vote that this is valid 17:02:47 <Uggla> I can try to reproduce, but I'm unsure how to easily deploy a multi cell env. 17:03:31 <gibi> we have multicell job we just need to see if we can enable some tempest there to catch this 17:04:59 <sean-k-mooney> thats in the sepc for what its porth 17:05:29 <sean-k-mooney> at least im 99% sure we called out that any files injected in the config drive would be lost with a cross cell resize 17:06:14 <sean-k-mooney> https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/cross-cell-resize.html#known-issues 17:06:16 <sean-k-mooney> limiation 3 17:06:30 <sean-k-mooney> Servers created with personality files, commonly known as file injection, that are resized across cells will lose the personality files since they are not persisted in the database 17:06:42 <gibi> sean-k-mooney: keypairs are not personality files 17:06:52 <gibi> afaik 17:06:56 <dansmith> correct 17:07:06 <dansmith> but they mentioned instance_extra 17:07:20 <dansmith> so if there's something we're not copying there and then regen'ing the configdrive... 17:07:44 <sean-k-mooney> oh it the keypari 17:07:55 <sean-k-mooney> ok that shoudl be copied and regenerated 17:08:13 <sean-k-mooney> i actully otught keyparis were in teh api db 17:08:33 <sean-k-mooney> not the cell db but i guess we embded them when we first create teh instance in the cell db? 17:08:40 <dansmith> keypairs themselves are I think (maybe) but the instance's attachment to them is in the main one of course 17:08:50 <sean-k-mooney> ack 17:09:49 <sean-k-mooney> im wondering if we could see this in ci. i think this is valid in anycase 17:10:12 <sean-k-mooney> we could create a repodcuer functional tests. in thoery tempest coudl detect this also 17:10:26 <sean-k-mooney> we just need to curl the metadata after the resize 17:10:32 <sean-k-mooney> or check the config drive i guess 17:10:49 <sean-k-mooney> presumable it workign now because the keypari is already in the authorized keys 17:11:24 <Uggla> sean-k-mooney, I'd like to try to do a reproducer. 17:11:30 <gibi> yepp we should be able to catch this in tempest 17:12:16 <sean-k-mooney> the workaround for now is just pass the keypari again on rebuild i guess 17:12:23 <Uggla> So if you all agree I will set this bug to valid and I'll try to do a reproducer. But I may need your help. 17:12:38 <sean-k-mooney> ack, sure shout if you hit issues 17:13:25 <Uggla> I will also update the bug with the workaround and remind limitation. 17:14:02 <Uggla> We are overtime, so I think we can wrap for today. 17:14:20 <sean-k-mooney> im not sure if we have multi cell functional tests today so that could be "fun" to make work 17:14:55 <sean-k-mooney> reproducing it in tempest will be simpler in this specific case. 17:15:10 <sean-k-mooney> oh we do https://github.com/openstack/nova/blob/master/nova/tests/functional/test_cross_cell_migrate.py 17:15:29 <dansmith> matt riedemann did that work, so I was *sure* there was functional testing for it :D 17:16:07 <sean-k-mooney> ack. getting diffent config to work in the fucntionla tests is still a bit fo a pain so i was unsure if we did or not 17:17:15 <Uggla> anything else ? 17:17:32 <Uggla> Thanks all and thanks for the extended time for bug triage. 17:17:37 <Uggla> #endmeeting 17:17:40 <Uggla> #endmeeting