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