Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-06-01
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 Uggla #endmeeting
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 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-06-01-16.00.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 Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-06-01-16.00.log.html
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
20:27:28 dansmith commented and +W'd
20:27:47 melwitt ok yeah confirmed it's in cache() where it does the wrong thing, I just re-read the comments in https://redhat.atlassian.net/browse/OSPRH-12784 where I first saw this issue
20:28:15 melwitt thanks dansmith
#openstack-nova - 2026-06-02
04:30:17 opendevreview Merged openstack/nova master: Disable interactive prompt on LVM image creation https://review.opendev.org/c/openstack/nova/+/990576
04:30:31 opendevreview Merged openstack/nova master: Use tempest_concurrency=1 for nova-vtpm job https://review.opendev.org/c/openstack/nova/+/984864
05:14:41 opendevreview Merged openstack/nova stable/2025.2: Fix resize to unpermitted flavors https://review.opendev.org/c/openstack/nova/+/988153
11:35:19 sean-k-mooney hi folks are we ok with running my cirros experiemtn for the next 2 weeks https://review.opendev.org/c/openstack/nova/+/990728 i have also created the revert https://review.opendev.org/c/openstack/nova/+/990729/1 im planning to update my pr https://github.com/cirros-dev/cirros/pull/132 to creat a seperate qcow image that is pre populated isntead of updating the existing one as
11:35:21 sean-k-mooney sugested by frickley but before we commit to that and look toward a release i want to actully confirm this fixes the issues
11:37:23 sean-k-mooney in terms of otehr reviews i woudl really love to close out https://review.opendev.org/c/openstack/nova/+/975872 and https://review.opendev.org/c/openstack/nova/+/984540 today if folks have time to reivew
11:37:48 sean-k-mooney gibi: stephenfin if time permits can ye add those to your queue
12:02:43 gibi sean-k-mooney: I trade https://review.opendev.org/c/openstack/nova/+/984540 for https://review.opendev.org/c/openstack/nova/+/986282
12:02:48 gibi :)

Earlier   Later