Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-06-01
16:30:14 cw0306-lee[m] Now, it can be reduced only when vm success to build on that host.
16:31:42 cw0306-lee[m] So i made this blueprint
16:32:18 cw0306-lee[m] Should i have to do something else to get approve?
16:32:38 Uggla cw0306-lee[m] do you have the link to the BP ?
16:33:03 gibi cw0306-lee[m]: why do we need another periodic? Isn't the stats flushed to the DB by the update_available_resources periodic? Can that periodic due the aging before flushing?
16:33:16 gibi /due/do
16:33:51 cw0306-lee[m] blueprints.launchpad.net/nova/+spec/reduce-build-fail-time-base
16:35:33 tkajinam gibi, maybe the proposal is not flushing (resetting the value to 0) but gradually decreasing it
16:36:04 Uggla cw0306-lee[m], so I think you want this as a spec less blue print.
16:36:56 tkajinam the decision may depend on how we control that "graduality"
16:37:13 gibi tkajinam: I mean https://github.com/openstack/nova/blob/380f657b5102707a3da676478e72fd96691e966b/nova/compute/manager.py#L2490-L2492 says we only update the stats in the DB at a the update_available_resources periodic
16:37:20 Uggla gibi, bauzas, tkajinam do you think this can be a SLBP ?
16:38:34 tkajinam gibi, ah, ok so we use separate mechanism to maintain the counter and report it to placement
16:38:55 gibi the counter ends up in the stats. I'm not sure where we update the placement trait
16:39:35 tkajinam I'm inclined to say we need a spec to discuss the mechanism to configure this feature.
16:40:23 cw0306-lee[m] https://github.com/openstack/nova/blob/380f657b5102707a3da676478e72fd96691e966b/nova/compute/stats.py#L153
16:40:53 cw0306-lee[m] So one reason i made this blueprint was that todo
16:42:01 cw0306-lee[m] I thought this is small topic that can be spec less blueprint, but if i need to write spec, i'll add spec until next time
16:43:02 cw0306-lee[m] cw0306-lee[m]: Todo -> fixme
16:44:38 Uggla cw0306-lee[m], problem from an admin perspective we are after soft spec freeze so we should not accept new specs. But if others are ok, maybe we can make a small exception.
16:45:09 gibi_ sure lets file a spec and see how complicated it is. I'm lost in finding how we manage the trait based on the stats
16:46:12 Uggla yes, fill a spec ASAP, and maybe if it is simple we can re-discuss/approve it next meeting/week.
16:46:44 Uggla but no promises it will be accepted.
16:47:19 Uggla does it sounds good to everobody ?
16:48:06 cw0306-lee[m] Sure. Thank you and i'll write the spec until next irc meeting!
16:48:17 Uggla also maybe, we will have Dan, he might explain what he wanted to do behind the fixme.
16:49:16 Uggla cw0306-lee[m], please ping me as when you have the spec. I'll add it to the tracking file
16:50:01 cw0306-lee[m] Ok, when i write spec, i'll ping you in irc! Thank you!
16:50:45 Uggla as we are almost at the top of the hour, I will not cover the 2 topics from Sean and left them for next week.
16:51:00 Uggla Anything you want to discuss in 5mn ?
16:51:18 gibi -
16:51:41 Uggla seems not, so I think we are done for today
16:51:47 Uggla Time to close, thanks for joining this meeting. Have a nice day/evening.
16:51:50 gibi thanks Uggla
16:51:54 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-06-01-16.00.log.html
16:51:54 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-06-01-16.00.txt
16:51:54 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-06-01-16.00.html
16:51:54 opendevmeet Meeting ended Mon Jun 1 16:51:54 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:51:54 Uggla #endmeeting
16:51:55 phildree[m] I wanted to ask if i could have a review on https://review.opendev.org/c/openstack/nova-specs/+/984384 but Uggla already wrote about this
16:52:13 elodilles thanks o/
16:52:19 Uggla phildree[m] I have mentionned it in the review point above
16:52:52 phildree[m] Thank you Uggla is there something i can do to it or do i just have to wait and see?
16:53:57 phildree[m] If there is nothing i can do then i might start implementing it for our infrastructure and if something happens down the line then i might push the code to the openstack repo as well
16:54:14 Uggla I think Dan was interested by this, so I suggest you add him as a reviewer.
16:55:12 Uggla I'll try to have a look too. So maybe it could ease the review for a last core reviewer.
16:55:33 phildree[m] Ok, thank you very much! :)
16:56:01 Uggla also try to ping people around Thursday, as this is a review day.
16:56:23 phildree[m] Good to know, will do!
16:57:25 Uggla They have a lot to review. But maybe they will find a slot before the spec freeze.
16:57:55 phildree[m] Understood :)
17:09:38 opendevreview Anton Iacobaeus proposed openstack/nova-specs master: Intel TDX support in libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/979608
17:29:13 Uggla gibi, sambork --> https://blueprints.launchpad.net/nova/+spec/complete-eventlet-removal SLBP
17:30:17 cardoe Uggla: thanks. I’m on PTO so I missed the meeting. I’ll be out next week.
17:32:32 Uggla cardoe, no worries I was aware of it, so I have just skip your topic. But keep mentioning the spec to have it approved.
17:39:17 cardoe Thank you.
18:55:00 gmaan melwitt: graceful shutdown spec is ready for 2nd core review https://review.opendev.org/c/openstack/nova-specs/+/986447
18:55:44 melwitt gmaan: I am reading through it now :) thanks for reminding
18:56:00 gmaan melwitt: thanks
19:29:06 opendevreview Merged openstack/nova-specs master: Spec for the graceful shutdown part2: Task tracking https://review.opendev.org/c/openstack/nova-specs/+/986447
19:45:32 melwitt gmaan: we could use some help reviewing sean-k-mooney fix for unified limits quota enforcement https://review.opendev.org/c/openstack/nova/+/975872 the fix is basically to incorporate RequestSpec into the quota checking to handle cases where the flavor extra spec(s) is not a 1-to-1 mapping to the placement resource classes. if you might be able to take a look
19:46:49 gmaan melwitt: ack, will check.
19:47:44 melwitt thx
19:53:30 melwitt dansmith: I wondered if you might be able to help review this bug fix about stale file existence (false positive) on NFS https://review.opendev.org/c/openstack/nova/+/988547 this has come up in downstream CI intermittent failures on NFS and then more recently in a customer case. the fix itself is very small
20:04:47 dansmith okay will look in a sec
20:05:33 melwitt thx
20:08:23 dansmith melwitt: hmm, I get the hack but.. could we not do something similar by just trying to cache the disk and fail if it exists (using the same exclusive create)?
20:09:15 dansmith meaning,
20:09:29 dansmith instead of trying to create it, and removing it if we succeed,
20:09:54 melwitt dansmith: oh, maybe. the exclusive create is the key (obviously) I was kinda torn between putting it for everything vs knowing the swap disk is the uniquely problematic case
20:09:55 dansmith just create it (empty) and if we succeeded, continue to use that file for create_image()
20:10:11 dansmith and if we failed to create because EEXIST, then we don't call create_image
20:10:29 dansmith I mean, I think you can do this in _create_swap() right?
20:10:47 dansmith just always call that, and if we fail to create it because it exists, then return, else continue with create_image() ?
20:11:08 melwitt I think maybe not bc _create_swap() is only for creating the backing file
20:11:48 melwitt (and I know, I know, we shouldn't have backing files for swap and eph but we do .... that's a separate change we have talked about making)
20:11:50 dansmith ..._create_swap() i the thing you're calling right after, right?
20:12:01 dansmith ohhh
20:12:15 melwitt that's the fetch func
20:12:16 dansmith swap.cache() "fetches" the backing image by calling _create_swap() I guess
20:12:17 melwitt yeah. hah
20:12:53 dansmith okay gross but anyway
20:12:59 melwitt yes, _create_swap() is only for creating the backing file if it doesn't exist, then the file existence of the actual child disk is a separate thing
20:13:08 melwitt yes, it is gross
20:13:15 dansmith I guess my point is.. do we have to create the fake thing, then remove it, then re-create with swap.cache()?
20:13:19 dansmith can we not just leave it?
20:15:04 dansmith the os.path.exists that gets fooled is the one in cache() right?
20:16:45 melwitt yes
20:17:27 dansmith and you didn't want to do this in cache (replace os.exists with a test create) just because it will affect more than swap?
20:17:29 melwitt or in create_image possibly
20:18:26 dansmith this just seems like a really really specific thing where we tickle a bit of behavior that could change (or be different on some other NFS implementation) and making it more direct/in-the-critical-path would be better
20:18:29 melwitt kinda. was torn about it. bc this is kind of an NFS-only problem (i.e. shared storage that is not ceph, I guess) and a swap-only problem. to do the exclusive probe
20:18:57 dansmith right, but like, CIFS could behave similarly but not exactly the same, for example
20:20:48 melwitt yeah ... I'm not opposed, just wasn't sure about adding a more expensive thing to all paths. I think your point is fair
20:21:15 dansmith because we could use os.posix_fallocate() on the fd we get from open instead of spawning the fallocate command, and then it would be way less expensive than it is today
20:21:52 melwitt oh, that's interesting
20:21:54 dansmith anyway, I'm just not jazzed about the obscurity of it.. but I'll just approve with a not-so-passive-aggressive comment about maybe following up and exploring ^
20:23:36 melwitt I knew you would be good for this review :) I was blown away by the false positive, period. and my knowledge limited compared to what you're talking about. I am ok with changing the approach, I'm sure sean-k-mooney will understand it too
20:26:37 dansmith NFS has this sort of behavior all the time, and it has changed over the years,
20:26:47 dansmith and I suspect also differs based on your mount arguments

Earlier   Later