| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-09 | |||
| 11:48:14 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: log number of green(thread|let)s periodically https://review.opendev.org/c/openstack/nova/+/841040 | |
| 11:50:59 | sean-k-mooney | gibi: o/ am yes i think nova should create the custom resouce classes in placement | |
| 11:51:28 | sean-k-mooney | the reason for this is we want to use CUSTOM_<VENDOR_ID>_<PRODUCT_ID> | |
| 11:51:47 | sean-k-mooney | when no RC has been specified in the device list | |
| 11:52:08 | sean-k-mooney | so i think it would be a better end user experince if those custom resouce classes were created automatically | |
| 11:52:09 | gibi | so resource_class=foobar is OK and nova will create CUSTOM_FOOBAR in placement | |
| 11:52:44 | sean-k-mooney | ah are you asking if nova should normalise and prepend the CUSTOM_ | |
| 11:52:58 | gibi | yep, as a follow up :) | |
| 11:53:12 | gibi | follow up question | |
| 11:53:49 | sean-k-mooney | i think that woudl be workable. i would prefer to encurage them to set CUSTOM_<whatever> | |
| 11:54:07 | sean-k-mooney | but i think its fine to prepend and normalise automatically | |
| 11:54:26 | gibi | a bit more user friendly if we normalize and prepend | |
| 11:54:28 | gibi | so I will go with that | |
| 11:54:51 | sean-k-mooney | yep just so long as we are smart and only prepend when needed | |
| 11:55:07 | gibi | OK, I can make it smart to avoid double custom | |
| 11:55:34 | gibi | OK | |
| 11:55:50 | gibi | next one is future proofing the RC | |
| 11:55:52 | gibi | https://review.opendev.org/c/openstack/nova-specs/+/791047/4/specs/zed/approved/pci-device-tracking-in-placement.rst#169 | |
| 11:56:41 | gibi | I think we support the case today when pci alias and neutorn sriov is configured in the same deployment | |
| 11:57:05 | gibi | also I think it is possible to consume the same type-VF either from alias or from port | |
| 11:57:44 | gibi | so for this case we need an RC name for the type-VF RP that is known before the scheduling for the sriov case | |
| 11:57:56 | gibi | SRIOV_NET_VF could be use for that | |
| 11:58:05 | gibi | as that already exists in os-traits | |
| 11:58:23 | sean-k-mooney | yes you can consume type-vf via alias | |
| 11:58:36 | sean-k-mooney | because VF and sriov have nothing to do with networking | |
| 11:58:48 | sean-k-mooney | you can have VFs for gpus or ssds | |
| 11:58:56 | gibi | true | |
| 11:59:02 | sean-k-mooney | the physical_network tag in the device list | |
| 11:59:14 | sean-k-mooney | is what marks it as a nic and is required for neutron consumtion | |
| 11:59:40 | sean-k-mooney | im not sure if we explictly prevent alaise form consuming device with physical_network set | |
| 11:59:51 | sean-k-mooney | but we could do that going forward i guess | |
| 11:59:55 | gibi | I think we did not prevent it today | |
| 12:00:03 | sean-k-mooney | ack | |
| 12:00:26 | sean-k-mooney | so for device with physical_network set | |
| 12:00:34 | gibi | we can simply say that resource_class will not be applicable if physical_network tag is present, and nova will use standard RC for these devices | |
| 12:00:46 | sean-k-mooney | i think its fine to mark them as SRIOV_NET_VF or SRIOV_NET_PF | |
| 12:00:49 | gibi | cool | |
| 12:01:01 | sean-k-mooney | we would likely track vdpa devices as SRIOV_NET_VF too | |
| 12:01:16 | sean-k-mooney | although i guess that could be SRIOV_NET_VDPA | |
| 12:01:33 | sean-k-mooney | that actully might make more sense not that i think of it | |
| 12:02:08 | gibi | yeah. but we don't have to decide it now, I just needed to make sure the that the current spec is future proof | |
| 12:02:10 | sean-k-mooney | so yes making RC and phsynet mutally exclsive i think is correct | |
| 12:02:22 | sean-k-mooney | yep | |
| 12:02:30 | gibi | OK | |
| 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? | |