| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-09 | |||
| 10:25:36 | ralonsoh | and in ceph.conf I have another one | |
| 10:25:52 | ralonsoh | then which one should I use in the second comptue? | |
| 10:28:09 | sean-k-mooney | the secret uuid is the cinder_ceph_uuid | |
| 10:28:26 | ralonsoh | yes, and it's generated by devstack-ceph | |
| 10:28:27 | ralonsoh | CEPH_FSID=$(uuidgen) | |
| 10:28:37 | sean-k-mooney | yep so you coudl doble check the cidner config | |
| 10:28:48 | sean-k-mooney | and determin which is the correct uuid value | |
| 10:29:27 | sean-k-mooney | ill quickly deploy with ceph and see if we can compare | |
| 10:33:48 | gibi | Uggla: responded in the manila spec | |
| 10:38:53 | sean-k-mooney | gibi: im just going to grab coffee but we can chat about the pci spec when ever suits | |
| 10:39:06 | sean-k-mooney | ill be back in 10 mins | |
| 10:45:13 | gibi | I will grab lunch so I will ping you later | |
| 10:47:52 | sean-k-mooney | cool no rush. | |
| 11:33:02 | gibi | sean-k-mooney: OK, I'm back | |
| 11:38:04 | gibi | sean-k-mooney: so the first question is simple. Will nova create the custom resource class mentioned in the [pci]device_list or we expect the deployer to pre-create that | |
| 11:38:24 | gibi | https://review.opendev.org/c/openstack/nova-specs/+/791047/4/specs/zed/approved/pci-device-tracking-in-placement.rst#156 | |
| 11:39:32 | gibi | I think in the vgpu case nova creates the custom RC | |
| 11:40:50 | gibi | as the config does not have a full RC but just some typename | |
| 11:40:55 | gibi | and nova generates the RC name from it | |
| 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 | |