| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-09 | |||
| 12:02:31 | gibi | next one | |
| 12:02:39 | sean-k-mooney | so you descoped the current spec to jsut the alias based passthough case yes | |
| 12:02:43 | gibi | yes | |
| 12:02:50 | sean-k-mooney | cool im fine with that by the way | |
| 12:02:53 | gibi | it is still complex enough | |
| 12:03:08 | sean-k-mooney | i want the neutron way to work too but it does not need to be in the initall mvp | |
| 12:03:14 | gibi | I just keep an eye on things not to create a dead end with the current spec | |
| 12:03:22 | sean-k-mooney | yep | |
| 12:03:36 | sean-k-mooney | ok so back ot your next question :) | |
| 12:03:55 | gibi | OK, the next one is simple. With the current proposal the RP is named <hostname>_pci_0000_84_00_0 | |
| 12:04:08 | gibi | if we follow the pGPUnaming | |
| 12:04:11 | gibi | PGPU naming | |
| 12:04:22 | gibi | is that OK? | |
| 12:04:49 | gibi | we could have a full normal PCI address if we want as the RP name charset is not restricted | |
| 12:04:50 | sean-k-mooney | am so i was not planning to use the lable for libvirt | |
| 12:05:13 | sean-k-mooney | the nodedev name pci_0000_84_00_0 | |
| 12:05:19 | sean-k-mooney | is not considerd stable by them | |
| 12:05:30 | gibi | ahh, good to know | |
| 12:05:37 | gibi | then I think it is better not to rely on it | |
| 12:05:39 | sean-k-mooney | so i was thinking it woudl be <hostname>_<pci addres in linux format> | |
| 12:05:47 | gibi | so like in DDDD:BB:AA.FF format? | |
| 12:05:50 | sean-k-mooney | yes | |
| 12:05:57 | gibi | OK, we can do that | |
| 12:06:03 | sean-k-mooney | is : allowed | |
| 12:06:08 | gibi | yes it is | |
| 12:06:17 | gibi | the RP name is free text | |
| 12:06:19 | sean-k-mooney | ok we could normalise | |
| 12:06:24 | sean-k-mooney | if not | |
| 12:06:31 | gibi | the traits and RCs are restricted | |
| 12:06:48 | sean-k-mooney | if we wanted to have pci_0000_84_00_0 by the way i would prefer that nova generated that | |
| 12:06:55 | sean-k-mooney | rahter then using the value directly form libvirt | |
| 12:07:56 | sean-k-mooney | but im oke wiht usei the bdf format above DDDD:BB:AA.FF | |
| 12:08:04 | gibi | ack | |
| 12:08:21 | gibi | next one | |
| 12:08:22 | sean-k-mooney | so one thing related to this | |
| 12:08:29 | gibi | go | |
| 12:08:53 | sean-k-mooney | even if you add the device to the device list using devname instead of the adress we would still use the pci adress in the RP name yes | |
| 12:09:03 | gibi | yes | |
| 12:09:04 | sean-k-mooney | i just want to make sure that detail is hidden form placement | |
| 12:09:06 | sean-k-mooney | cool | |
| 12:09:25 | gibi | if we need the devname for any reason during the scheduling we can add that as a trait | |
| 12:09:51 | sean-k-mooney | yes we could. currently its not used in the alias or pci request object | |
| 12:09:55 | sean-k-mooney | so we shoudl not | |
| 12:10:16 | sean-k-mooney | but if we did a trait woudl be workable | |
| 12:10:55 | gibi | if not needed then we wont add it :) | |
| 12:11:01 | sean-k-mooney | :) | |
| 12:11:03 | gibi | so the next question is related | |
| 12:11:15 | gibi | what traits nova needs to add automatically? | |
| 12:11:30 | gibi | only the ones mentioned in the device_lsit | |
| 12:11:31 | gibi | ? | |
| 12:11:47 | gibi | or we want to automate things like adding capabilities as traits | |
| 12:12:10 | sean-k-mooney | ah so yes the capablitiy traits shoudl be added in my view | |
| 12:12:22 | sean-k-mooney | they were intended to be reported to placement orgianly | |
| 12:12:29 | gibi | OK, that make sense | |
| 12:13:00 | sean-k-mooney | so if i rememebr correctly you were suggeting allow additivie only traits to be listed in the device_list | |
| 12:13:00 | gibi | do we have in the code somewhere listed what are the capabilities we parse? or we parse verything? | |
| 12:13:04 | gibi | *everything | |
| 12:13:16 | sean-k-mooney | gibi: im looking for the code now | |
| 12:13:31 | sean-k-mooney | but we had code to normalise the capablites and report them to placement that ralonsoh wrote in the past | |
| 12:13:33 | gibi | sean-k-mooney: yepp the today spec only supports additive traits | |
| 12:14:45 | sean-k-mooney | https://review.opendev.org/q/topic:bp%252Fenable-sriov-nic-features | |
| 12:15:09 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/466051 specficically | |
| 12:15:18 | sean-k-mooney | but you might be able to reuse some of the other work | |
| 12:16:19 | sean-k-mooney | gibi: the traits have already been added to os-traits https://github.com/openstack/os-traits/blob/master/os_traits/hw/nic/offload.py | |
| 12:17:18 | gibi | thanks, this helps | |
| 12:17:44 | gibi | so lets report capabilities as traits | |
| 12:17:59 | gibi | and then I will amend the spec to allow removing traits via device_list | |
| 12:18:08 | gibi | to disable capability | |
| 12:18:09 | sean-k-mooney | yep. right now this only makes sense for neutron nics really | |
| 12:18:20 | sean-k-mooney | since we dont really gather capablities for other devices | |
| 12:18:30 | gibi | ahh | |
| 12:18:36 | gibi | so no generic PCI caps | |
| 12:18:37 | sean-k-mooney | although remote_mannaged might be the excption | |
| 12:18:56 | sean-k-mooney | well for the remote managed deviecs we now have the vpd | |
| 12:18:57 | sean-k-mooney | capablity | |
| 12:19:17 | sean-k-mooney | that is not yet a trait so maybe we would want to report that | |
| 12:19:48 | sean-k-mooney | gibi: i think for the inital version we could keep it to jsut operator provided traits | |
| 12:19:54 | sean-k-mooney | if we want to keep it simple | |
| 12:20:33 | sean-k-mooney | then in the future we can auto discover device capablities and report them if that makes sense | |
| 12:20:44 | gibi | yeah that make sense, it is easy to add later | |
| 12:20:57 | gibi | so keeping traits just additive now as well | |
| 12:21:58 | gibi | OK | |
| 12:22:21 | gibi | next one | |
| 12:22:23 | gibi | https://review.opendev.org/c/openstack/nova-specs/+/791047/4/specs/zed/approved/pci-device-tracking-in-placement.rst#288 | |
| 12:22:33 | gibi | What to do if both ``resource_class`` and ``vendor_id`` and ``product_id`` are provided in the alias? | |
| 12:23:10 | sean-k-mooney | good question. i guess we have too options | |
| 12:23:15 | sean-k-mooney | first is consider that an error | |
| 12:23:33 | sean-k-mooney | second is use the resouce_class for placment queries | |
| 12:23:50 | sean-k-mooney | and the the rest for the pci/numa filter | |
| 12:23:53 | gibi | the only use case I can think of is that deployer use a generic RC but then later want to refine the alias via product id | |
| 12:24:20 | sean-k-mooney | my secret plan is to eventually remove the need for the alias | |
| 12:24:41 | sean-k-mooney | so over time it woudl be nice if we coudl move to jsut having the resouce class in the alias | |
| 12:24:42 | gibi | do you want to go with flavor extra_spec based resource? | |
| 12:25:00 | sean-k-mooney | yes and no | |
| 12:25:11 | sean-k-mooney | i current hate that we allow grouping in the extra_specs | |
| 12:25:36 | sean-k-mooney | so part of me wants to keep the alisa as we can insulate operators form that | |
| 12:26:14 | sean-k-mooney | but i do kind of like the idea of have just resouce:CUSTOM_<whatever>=1 | |
| 12:26:51 | gibi | OK, I get the goal that we want to move deployers to RC based alias in the future and if the deployer still want product id based filtering then the deployer can use traits for that | |
| 12:26:55 | sean-k-mooney | so i think having the RC take prescidence for the placment query and allowign vendor_id and product_id makes sense | |
| 12:27:40 | gibi | OK | |