Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-07-08
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: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

Earlier   Later