Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-07-08
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 :)
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 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-07-08-16.00.log.html
17:03:35 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-07-08-16.00.txt
17:03:35 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-07-08-16.00.html
17:03:35 opendevmeet Meeting ended Tue Jul 8 17:03:35 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:03:35 Uggla #endmeeting

Earlier   Later