Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-07-08
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 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:29:43 Uggla Fisrt bug: https://bugs.launchpad.net/nova/+bug/2116186 - Py3.13: nova-conductor crash during report status
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 Uggla ok so, can we consider it triaged or valid ?
16:49:18 gibi this works today
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 gibi same as {address="", managed=no}
16:55:49 sean-k-mooney that is a very severy bug that should prevent startup
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 :)

Earlier   Later