16:00:14 <Uggla> #startmeeting nova 16:00:14 <opendevmeet> Meeting started Tue Jul 8 16:00:14 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:14 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:14 <opendevmeet> The meeting name has been set to 'nova' 16:00:24 <Uggla> Hello everyone 16:01:07 <fwiesel> o/ 16:01:21 <elodilles> o/ 16:03:04 <bauzas> o/ 16:03:14 <Uggla> Let's start slowly so people could join 16:03:23 <Uggla> #info No Critical bug 16:03:35 <Uggla> oops 16:03:37 <Uggla> #topic Bugs (stuck/critical) 16:03:48 <Uggla> #info No Critical bug 16:03:57 <Uggla> #topic Gate status 16:04:04 <Uggla> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16:04:12 <Uggla> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal 16:04:21 <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:04:28 <Uggla> #info Please look at the gate failures and file a bug report with the gate-failure tag. 16:04:35 <Uggla> #info Please try to provide a meaningful comment when you recheck 16:04:50 <Uggla> #info https://bugs.launchpad.net/nova/+bug/2115980 opened by gibi. It seems nova next has regular failure due to this. 16:05:17 <Uggla> gibi, do you have more info about ^ 16:05:53 <clarkb> the underlying issue is that zuul launcher can in some exceptional circumstances assign nodes to multiple providers within the same nodeset. This is due to zuul launcher wanting to be able to support k8s pods and openstack vms in the same nodeset 16:06:19 <clarkb> unfortauntely there were a few bugs (I think 2 or 3 at this point) that allowed it to mix providers more often than expected. The last of these known bugs was fixed around 2200UTC yseterday 16:06:35 <gibi> yepp the latest from me is that I'm not seeing the failure today any more 16:06:41 <clarkb> with each of the bugfixes the occurence of this issue should be lessened. And hopefully if we've fixed the bugs then the issue goes away 16:07:08 <gibi> I will keep the bug around for couple of days then I will close it if the problem does not re-occure 16:08:03 <Uggla> thanks clarkb, I appreciate your inputs. 16:08:33 <Uggla> thanks gibi 16:08:51 <Uggla> skipping next topic because gmann is not available. 16:09:08 <Uggla> #topic Release Planning 16:09:17 <Uggla> #link https://releases.openstack.org/flamingo/schedule.html 16:09:25 <Uggla> #info Nova deadlines are set in the above schedule 16:09:50 <Uggla> Spec freeze was last week. So no new specs. 16:10:15 <Uggla> #topic Review priorities 16:10:31 <Uggla> #link https://etherpad.opendev.org/p/nova-2025.2-status 16:12:02 <Uggla> We had a lot of interest just before the spec freeze around io threads. 16:12:58 <Uggla> Although, the specs were not approved this cycle. We may open a 2026.1 "directory" to keep the momentum around this activity. 16:13:53 <Uggla> #topic OpenAPI 16:14:01 <Uggla> #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned 16:14:23 <Uggla> #info 19 remaining. Same as last week. 16:14:36 <Uggla> #topic Stable Branches 16:14:51 <Uggla> elodilles, please go ahead. 16:14:59 <elodilles> i was on vacation last week, so i might missed some stuff 16:15:04 <elodilles> otherwise, i'm not aware of any issue with stable gates 16:15:17 <elodilles> so that's all, to be quick o:) 16:15:25 <elodilles> Uggla: back to you 16:15:45 <Uggla> thx elodilles 16:16:00 <Uggla> #topic vmwareapi 3rd-party CI efforts Highlights 16:16:08 <fwiesel> Hi, no updates from my side. 16:16:21 <Uggla> fwiesel, thanks. 16:16:29 <Uggla> #topic Gibi's news about eventlet removal. 16:16:34 <Uggla> #link Blog: https://gibizer.github.io/categories/eventlet/ 16:16:42 <Uggla> #link nova-scheduler series is ready for core review, starting at https://review.opendev.org/c/openstack/nova/+/947966 16:16:58 <Uggla> gibi, do you want to say something about eventlet removal ? 16:17:18 <gibi> only that we are slowly landing the approved patches as the gate allows 16:17:35 <gibi> we have one patch left that is approved but not landed yet 16:17:43 <gibi> the series is in reviewable state 16:18:01 <gibi> I'm only tracking minor comment at the moment 16:18:03 <gibi> that is all 16:18:58 <Uggla> thx gibi 16:19:16 <Uggla> #topic Open discussion 16:19:39 <Uggla> #info (Uggla) I will be on PTO the 15th and 22nd July. bauzas will run the meeting on my behalf. 16:20:28 <Uggla> This is the only thing I wanted to share, thanks bauzas ^ 16:20:50 <Uggla> Someone wants to discuss about something else ? 16:20:52 <gibi> I have one topic, mostly a heads up. The grenade job semi frequently times out while dumping DBs. Recent occurence https://zuul.opendev.org/t/openstack/build/1328f6c40c5845fa800753d338551e06 16:21:42 <gibi> I did not see any logs telling me why dumping the DB takes so much time. But maybe we just need to disable DB dumping on the gate by default 16:22:15 <Uggla> What is the purpose of the dump ? 16:22:39 <gibi> I guess to troubleshoot DB schema upgrade 16:22:58 <gibi> but I did not tracked down where we enable the dumpgin 16:23:10 <gibi> I will bring this up next week when we have more cores around 16:23:24 <gibi> and If my time allows then I will propose a patch to disable it 16:23:55 <Uggla> yep no worries, tbh the question was more to satisfy my curiosity. 16:25:24 <Uggla> Do you have some energy for bug triage ? 16:26:04 <gibi> If it just you and me are here for triage then maybe one or two bugs 16:27:11 <Uggla> gibi, let's do it. 16:27:23 <Uggla> #topic Bug scrubbing 16:27:30 <Uggla> #info up to 167 :( Increased a lot on the 16th of June. 16:27:38 <Uggla> #link: https://etherpad.opendev.org/p/nova-bug-selection-for-triaging#L4 16:27:44 <Uggla> #link: https://truc.uggla.fr/ I kicked off this draft page to follow open bugs. 16:29:43 <Uggla> Fisrt bug: https://bugs.launchpad.net/nova/+bug/2116186 - Py3.13: nova-conductor crash during report status 16:29:43 <Uggla> Here I'm more looking at what we should do with py3.13 bugs? I set a "python313" tag on the bug at least. 16:30:23 <gibi> I know zigo wants help fixing them. I'm not sure how much capacity we have to help there. 16:31:56 <gibi> We will have more priority fixing them once we want to make py313 suppoted officially 16:32:23 <Uggla> I'm a bit torn about looking at 3.13 bug. Should we wait eventlet removal first ? 16:33:39 <gibi> to look at the bugs we need motivation, when the decision happen that openstack officially supports 3.13 we will have such motivation. 16:33:57 <Uggla> And should we keep this kind of but to new or set them to deferred ? What's your opinion ? 16:34:06 <gibi> evetlet might become supportable on top of 3.13 so it is unrelated 16:35:03 <Uggla> gibi, you mean some people working in that direction ? ^ 16:35:05 <gibi> I have no hard opinion. I would keep it as is for now as I don't see the value of the deferred paperwork here 16:35:33 <gibi> Uggla: yes, herve and the folks are working on that 16:36:04 <Uggla> oh so fixing eventlet (OO) 16:37:17 <gibi> eventlet is more supportable in 313 than in 314 16:38:11 <Uggla> ok good to know. 16:38:32 <Uggla> Regarding the bug, I keep it in the current state. 16:39:14 <Uggla> Next one: https://bugs.launchpad.net/nova/+bug/2115726, I think it is just a matter to triage it as it looks you worked on it? 16:40:16 <gibi> it needs dicussion with the core team I have at least followup question to Sean's statements in the bug. 16:41:05 <gibi> either we doc the behavior or we rip it off, but if we rip it off we need to consider other adjacent features giving the same result as what Sean does not like 16:41:15 <sean-k-mooney> ya i dont think 3.14 is even remotely possible 16:41:43 <Uggla> Hi sean-k-mooney 16:42:43 <sean-k-mooney> o/ 16:43:09 <sean-k-mooney> my issue with this si form my perspecitive this behvior was never docudment or approved in any of the specs that altered the fucntionaltiy 16:43:36 <sean-k-mooney> i dont belive we shoudl document casese where we didnt to proper input validation and supprot them just becasue we didnt catch it in code review 16:43:59 <sean-k-mooney> not when it impact both the number of nested RPs in palcmenet and the dbrow count in the pci devices table 16:44:33 <sean-k-mooney> if this was a deliberate chocie by using address="*" that different 16:44:44 <gibi> the dev_spec has the notion of partial match this is an edge case of such partial match, so if we remove this then we should remove other partial matches that potentially create a lot of rows 16:44:57 <gibi> what about address=""? 16:45:09 <sean-k-mooney> well that shoudl also be an error 16:45:15 <gibi> what about vendor_if=8086 without product id? 16:45:19 <sean-k-mooney> its not a viald adress or glob 16:45:33 <gibi> sean-k-mooney: we do support partial address match toady 16:45:38 <gibi> you dont need the * 16:45:39 <sean-k-mooney> vendor_id is ment ot be combdiend with product id or an address 16:46:02 <sean-k-mooney> gibi: that is again not one of the docuemnted cases that shoudl work 16:46:19 <sean-k-mooney> it can work if you have one of the ohter matchers 16:46:37 <gibi> I do belive that both globbing by address pieces and both partial address string match is explicitly implemented 16:46:55 <sean-k-mooney> an empty string is not a partial match 16:46:59 <sean-k-mooney> or a blog 16:47:15 <sean-k-mooney> *glob 16:47:44 <gibi> it is by regex 16:47:46 <gibi> Both traditional glob style and regular expression syntax is supported. 16:48:04 <gibi> https://docs.openstack.org/nova/latest/configuration/config.html#pci.device_spec 16:48:08 <sean-k-mooney> regex supprot requries the dict syntaxz 16:48:16 <sean-k-mooney> it not supproted in the string syntax 16:48:23 <gibi> I'm note sure 16:48:49 <sean-k-mooney> i am pretty sure 16:48:50 <gibi> anyhow there is a lot of things that works today and we need discussion with quorum what to remove and what to document 16:49:02 <sean-k-mooney> i agree 16:49:09 * bauzas apologies, was in a long convoy on the phone 16:49:14 <gibi> device_spec = { "vendor_id":"8086", "product_id":"10c9", "address": "0000:0c:"} 16:49:15 <sean-k-mooney> i would consieder supprot {} as a wild card to be a feature nto a bug 16:49:18 <gibi> this works today 16:49:18 <Uggla> ok so, can we consider it triaged or valid ? 16:49:43 <Uggla> As I understand something is required here. 16:49:53 <sean-k-mooney> Uggla: we both agree its valid but not what the actull issue is and the actual fix 16:49:55 <bauzas> let's just document this 16:50:04 <sean-k-mooney> i consider it a input validation bug 16:50:10 <bauzas> at least for now 16:50:22 <sean-k-mooney> im not okk wiht documenting it as supproted 16:50:37 <sean-k-mooney> if we want to say that it work but is not supproted andy you cant rely on it then sure 16:50:55 <sean-k-mooney> but this was never inteded to work so im not oke with commiting to supprot it going forward 16:50:57 <bauzas> sean-k-mooney: I'm not saying we should document it as "it's supported" 16:51:18 <bauzas> I just want to document something like "note: if you use {}, then blah" 16:51:31 <bauzas> or "bug note" if you prefer 16:51:40 <bauzas> or known issue 16:51:50 <sean-k-mooney> i can by into this as a known issue 16:52:05 <gibi> My original plan was to describe the two types of dev_spec fields. The one that we use to filter the devices and the one that we use to enhance the devices. Then in the filtering fields I would go an detail how partial match works. But based on Sean's view I would go -1 or -2 so I'm not going to do it 16:52:30 <sean-k-mooney> gibi: those are not seperate things 16:52:44 <sean-k-mooney> you are to enrich devices sepereatly form filtering 16:53:01 <sean-k-mooney> there are ways to do that today beucase of bug 16:53:19 <sean-k-mooney> but that was not how this was intened to work form my perspective 16:53:27 <gibi> traits, resource_class, otu are clearly not filtering anything 16:53:45 <gibi> they are just enhancing the already filtered data 16:53:46 <sean-k-mooney> correct but they shoudl only be applied to the same devspec that they are defiend on 16:54:04 <gibi> and they do 16:54:24 <sean-k-mooney> ok so your not advocating for somethign like {managed=no} 16:54:29 <sean-k-mooney> to set that on all devices 16:54:53 <sean-k-mooney> like that is an invalid devspec form my perspetive 16:55:21 <gibi> if you say {managed=no} then your dev_spec is matching to all devices today and enhancing them with the managed flag 16:55:35 <sean-k-mooney> ya so that is not valid in my opion 16:55:49 <sean-k-mooney> that is a very severy bug that should prevent startup 16:55:49 <gibi> same as {address="", managed=no} 16:55:55 <sean-k-mooney> which is also not valid 16:56:18 <gibi> does {address="0000", managed=no} valid? 16:56:29 <gibi> it is accepted today 16:56:34 <gibi> and matching most of the devices :) 16:56:40 <sean-k-mooney> if you read our docs then no 16:56:49 <sean-k-mooney> and i don tcondier what works to defien the contact 16:56:52 <gibi> so the docs is incomplete 16:56:55 <sean-k-mooney> wha twe wrote in the specs does 16:57:06 <gibi> then we would never fix a doc bug :) 16:57:07 <bauzas> I agree with gibi here 16:57:14 <bauzas> we need a doc, please 16:57:16 <sean-k-mooney> the docs are correct 16:57:20 <sean-k-mooney> the code is wrong 16:57:35 <gibi> anyhow. We need a list of what is supported and what is not supported and we need to agree on it 16:57:42 <gibi> then we can fix whatever need fixing 16:57:52 <gibi> we currently cannot agree on what is supported and what is not 16:57:56 <gibi> so I suggest tabling this 16:58:09 <sean-k-mooney> by the way {address="0000", managed=no} is technially valid today 16:58:14 <gibi> maybe a PTG discussion is in order with preparation listing all the cases that accepted today 16:58:27 <sean-k-mooney> but that only because we supprot partlial adresses 16:58:48 <Uggla> Can we move to the next one. As I'm unsure we manage to get out with something here. 16:58:53 <gibi> so address="0" is also a partial address as well as "" 16:58:59 <gibi> where is the line? 16:59:18 <sean-k-mooney> we draw it based on what we agreed in the specs orginally 16:59:47 <sean-k-mooney> and if thre was a bug in the spec we fix it with a new one or a bug that we dicusss in detail 17:00:05 <gibi> I agree that we need to discuss in detail 17:00:26 <Uggla> yep please can we stop on that one. 17:00:48 <gibi> we need a detailed plan what to rip off we cannot rip off address="" support if we keep address="0" I tink 17:00:50 <bauzas> I need to leave now 17:00:53 <bauzas> o/ 17:01:21 <Uggla> Can we have a look at the latest one: https://bugs.launchpad.net/nova/+bug/2115870 I guess it is valid looking aat the patch attached. 17:02:10 <gibi> I have no context on volume retype 17:02:33 <sean-k-mooney> lets leave that for now and come back next week 17:03:08 <Uggla> ok end for today. 17:03:29 <Uggla> Thanks all 17:03:35 <Uggla> #endmeeting