| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-20 | |||
| 11:52:33 | sean-k-mooney | if we were to go the provider.yaml route | |
| 11:52:38 | sean-k-mooney | then it would be a custom trait | |
| 11:52:48 | sean-k-mooney | whcih we can do but i would prefer to do that in code | |
| 11:52:57 | sean-k-mooney | i can drop it but it fells like a hack to not have it | |
| 11:53:04 | stephenfin | True. Same issue with PCI devices, NUMA topologies etc. though | |
| 11:53:28 | sean-k-mooney | not entirely the same thign although i waint traits for numa support | |
| 11:53:30 | stephenfin | Yeah, I'd agree with this normally but it does feel like we're using a trait as a stand in for proper resource reporting | |
| 11:53:33 | sean-k-mooney | i just have not needed them | |
| 11:53:56 | sean-k-mooney | well traits are for capablities | |
| 11:54:30 | sean-k-mooney | lets see what gibi thinks and ill go with whatever the two of ye decied unless other weigh in | |
| 11:54:37 | stephenfin | Yeah, it's a very fuzzy line, that's for sure | |
| 11:54:41 | stephenfin | Makes sense | |
| 11:55:22 | stephenfin | as for your PCI devices in placement question, RE: what to do with VFs when a PF is consumed | |
| 11:55:28 | stephenfin | I'd just kill that "feature" | |
| 11:55:59 | stephenfin | make it necessary to state whether you want to allow passthrough of the PF or the VFs, and only report one | |
| 11:56:01 | sean-k-mooney | well it has been a feature for a very long time making it so you dont have to pre allocated devices | |
| 11:56:12 | sean-k-mooney | but its very similar to how isolate used to work | |
| 11:56:20 | sean-k-mooney | its the same problem form a plamcent point of view | |
| 11:56:25 | stephenfin | Yup | |
| 11:56:29 | sean-k-mooney | so killing it would be valid but contentious | |
| 11:56:38 | sean-k-mooney | which is why i dont think we will agree on that by tomorowy | |
| 11:56:43 | stephenfin | I agree | |
| 11:56:48 | stephenfin | Plus, you already have two specs | |
| 11:56:57 | stephenfin | More than enough for the three months we have left :) | |
| 11:57:22 | stephenfin | Anywho | |
| 12:02:37 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: libvirt: Add support for flavor and image defined ephemeral encryption https://review.opendev.org/c/openstack/nova-specs/+/771474 | |
| 12:03:57 | sean-k-mooney | stephenfin: we dont have 3 months left | |
| 12:04:52 | sean-k-mooney | stephenfin: m3 is march 11th so half that we have 6 weeks left but i agree | |
| 12:05:13 | sean-k-mooney | its 3 months till the offical release | |
| 12:05:24 | sean-k-mooney | april 15th | |
| 12:22:20 | openstackgerrit | John Garbutt proposed openstack/nova master: Fix PCI passthrough race on reschedule (refresh) https://review.opendev.org/c/openstack/nova/+/710848 | |
| 13:09:14 | sean-k-mooney | johnthetubaguy: since your about QQ do you know if anyoen is working on unified limits this cycle | |
| 13:10:31 | sean-k-mooney | johnthetubaguy: i dont see a spec approved just wondering if that is on holed indefinetly or are people still makeing progress? melwitt you might also know? | |
| 13:32:35 | openstackgerrit | Merged openstack/nova master: libvirt: Mock get_arch during some stable rescue unit tests https://review.opendev.org/c/openstack/nova/+/769916 | |
| 13:41:24 | gibi | stephenfin: we have customers that are relying the feature that allows consuming the whole PF or consuming just VFs from it dynamically. So while I like the idea to uncomplicate things I have to agree with sean-k-mooney that this feature is alreasy sold and supported out there | |
| 13:42:33 | gibi | sean-k-mooney: which trait specifically you dicussed above with stephenfin above? | |
| 13:45:11 | sean-k-mooney | gibi: the vdpa one | |
| 13:46:10 | sean-k-mooney | gibi: ill get you the link to the comment in the spec | |
| 13:46:35 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/764999/4/specs/wallaby/approved/libvirt-vdpa-support.rst#79 | |
| 13:47:41 | sean-k-mooney | gibi: i can drop the trait and rely on the pci passthough filter but i wante to provide a slightly better schdulign expericne before looking at tracking in plamcnet next cycle when i have more time/brain power | |
| 13:48:11 | sean-k-mooney | gibi: unfortuetlly the PF/VF thing is the same problem we had with hyperthread and PCPUs | |
| 13:48:39 | sean-k-mooney | fundementally we cant express requirments to placment that require different resouced dependding on the selected host | |
| 13:49:23 | sean-k-mooney | so if we want to track pci devices in plamcnet in the long term we either have to try and update the allcoation candiate after we claim it or we have to remove the fature | |
| 13:49:51 | sean-k-mooney | the same way we removed the ablity for the isolate policy to claim both hypertreads on host with SMT enabled | |
| 13:50:20 | sean-k-mooney | anywya pci device in placment is hopefully out of scope for vdpa this cycle | |
| 13:51:43 | sean-k-mooney | gibi: so the options we have are no trait and just rely on pci passhtough filter, standard trait added by prefilter, custom trati added by prefilter, and custom trait added by provider.yaml and manually in the flavor/image | |
| 13:59:56 | gibi | I agree that currenty no support in placement to make some VF resource unavailable if the parent PF is consumed. Current it is done by the PCI tracker and I guess we can keep this behavior in the compute node even after PCI is modelled in placement. E.g. the pci claim that happens on the compute can simply reserve the VFs in placement if the PF is claimed | |
| 14:00:26 | gibi | it has the same racy behavior as of today | |
| 14:00:30 | gibi | but not worse | |
| 14:00:59 | sean-k-mooney | yep if we do the claim in the conductor imieatly after the allcoation calim | |
| 14:01:04 | sean-k-mooney | we can make that better | |
| 14:01:12 | gibi | yes, that can be done as well | |
| 14:01:29 | sean-k-mooney | espcially if said claim also make sure the resrvation in placment is updated first | |
| 14:02:03 | gibi | we can basically add a placement post-filter that gets the selected allocation candidate that is being sent back to placement and adds the extra reservation to it | |
| 14:02:29 | sean-k-mooney | ya that an option but not in the next 6 weeks right | |
| 14:02:36 | gibi | yes, it is after W | |
| 14:02:50 | sean-k-mooney | ok | |
| 14:02:52 | gibi | agree | |
| 14:03:07 | sean-k-mooney | so the real question is what to do for W | |
| 14:03:12 | gibi | yes | |
| 14:03:24 | sean-k-mooney | standard tait that wont be need after devices are in placment | |
| 14:03:28 | sean-k-mooney | custom trait | |
| 14:03:33 | sean-k-mooney | or no trait | |
| 14:03:56 | gibi | the custom trait solution would still require the pre-filter to be implemented, isn't it? | |
| 14:04:19 | sean-k-mooney | i think so | |
| 14:04:30 | sean-k-mooney | provider.yaml coudl report it | |
| 14:04:33 | gibi | then the custom trait is bad option in my eyes | |
| 14:04:45 | sean-k-mooney | but requesting would need a flavor/image with it | |
| 14:05:19 | sean-k-mooney | and using a specal falvor/imge for vdpa seams wrong in my eyes | |
| 14:05:26 | gibi | agree ^ | |
| 14:05:34 | gibi | vdpa is a port specific thing | |
| 14:05:34 | sean-k-mooney | there is no way to add custom traits to a neutron port right? | |
| 14:05:42 | sean-k-mooney | yep exactly | |
| 14:05:44 | gibi | sean-k-mooney: not from the user side | |
| 14:05:50 | gibi | neutron could add it from code | |
| 14:05:56 | sean-k-mooney | ya that is what i tought | |
| 14:05:57 | gibi | but that also mehh | |
| 14:06:01 | sean-k-mooney | via the resouce requests right | |
| 14:06:04 | gibi | right | |
| 14:06:10 | sean-k-mooney | but we are not using them for this | |
| 14:06:16 | gibi | if there is qos then the vnic type is added as custom triat | |
| 14:06:17 | sean-k-mooney | so unfortunetly not useful | |
| 14:06:39 | sean-k-mooney | am dont you mean physnet | |
| 14:06:42 | sean-k-mooney | not vnic type | |
| 14:06:44 | gibi | hm, | |
| 14:07:08 | sean-k-mooney | anyway it wont work without neutron code chagnes is the imporant point | |
| 14:07:19 | sean-k-mooney | so really its standard trait with prefilter or no trait. | |
| 14:07:37 | gibi | both | |
| 14:07:57 | gibi | both the physnet and the vnic_type is a custom trait in qos | |
| 14:08:09 | sean-k-mooney | oh that is what you ment :) | |
| 14:08:15 | gibi | anyhow | |
| 14:08:15 | sean-k-mooney | ok good to know | |
| 14:08:28 | gibi | I agree it is either standard trait, or nothing | |
| 14:08:39 | sean-k-mooney | stephenfin: ^ | |
| 14:09:02 | sean-k-mooney | do either of ye have a preference then | |
| 14:09:12 | sean-k-mooney | i feel like ye are leaning towoard nothing? | |
| 14:09:23 | sean-k-mooney | and just using the pci passthough filter? | |
| 14:09:33 | gibi | personally if having no trait and a possibility of a bugreport due to the limit in allocation candidates that motivates us to do the PCI in placement then | |
| 14:09:46 | gibi | yes, I would go with nothing | |
| 14:09:54 | gibi | and focus on PCI in placement in X | |