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