| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-20 | |||
| 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 | sean-k-mooney | there is no way to add custom traits to a neutron port right? | |
| 14:05:34 | gibi | vdpa is a port specific thing | |
| 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 | sean-k-mooney | ok good to know | |
| 14:08:15 | gibi | anyhow | |
| 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 | |
| 14:10:06 | gibi | (I have my personal reason to look into PCI in placement soon) | |
| 14:10:08 | stephenfin | yeah, I vote nothing | |
| 14:10:32 | sean-k-mooney | ya personally i like the possibel cross project goal of decalring X a maintaince cycle | |
| 14:10:36 | gibi | the current PCIFilter based qos + pci solution has limitations until PCI in placement is a thing | |
| 14:10:49 | sean-k-mooney | but i am happy to push internally that we use that to pay donw our pci debth | |
| 14:11:16 | gibi | sean-k-mooney: lets have X a maintenance cylce where we discuss the PCI in placement from spec perspective :D | |
| 14:11:50 | sean-k-mooney | hehe well i would like to spend some time fixing some of thepci related move operations but ya | |
| 14:11:54 | gibi | and yes, technical dept removal is a good form of maintenance | |
| 14:12:14 | sean-k-mooney | ok ill update the spec to remove the trait and prefilter | |
| 14:12:24 | sean-k-mooney | and abandon the patches i submited for those | |
| 14:12:36 | gibi | sean-k-mooney: thanks | |
| 14:12:49 | sean-k-mooney | gibi: stephenfin was that the only outstanding question ye had | |
| 14:12:57 | sean-k-mooney | is so ill respin the spec now | |
| 14:12:57 | stephenfin | yup, for me anyway | |
| 14:13:07 | gibi | sean-k-mooney: nothing else from me on that sepc | |
| 14:13:08 | gibi | spec | |
| 14:13:22 | sean-k-mooney | ok thanks both of you. | |
| 14:14:17 | sean-k-mooney | gibi: your main concen with the port numa policies is the precidence right | |
| 14:14:55 | sean-k-mooney | ill poke other to review in our internal team meeting but should i add it to the adgenda for tomorrows | |
| 14:15:10 | sean-k-mooney | or maybe a ML post and ask for feedback there? | |
| 14:15:37 | gibi | sean-k-mooney: anything that puts more eyes on the spec from the perspective | |
| 14:15:55 | gibi | I think tomorrows agenda is a good idea | |
| 14:16:06 | gibi | if no objection there then I will upgrade my vote to +2 | |
| 14:16:55 | sean-k-mooney | thanks ok ill send a short mail to the list and say it to the redhat folk internally too and we can decied tomorrow | |
| 14:19:28 | nightmare_unreal | is there a reason why placement takes 1.0 api as default ? why it does not take latest like in nova | |
| 14:21:06 | sean-k-mooney | latest is a legacy thing for the nova client | |
| 14:21:59 | sean-k-mooney | latest also might not always do what you think it wont nessiarly do negociation | |
| 14:28:25 | nightmare_unreal | is there a way to specify/config that ? | |
| 14:30:22 | sean-k-mooney | so osc when you use latest just uses that latest version constnat in the nova_client lib | |
| 14:30:28 | sean-k-mooney | it does not negociatation | |
| 14:30:38 | sean-k-mooney | nova client if you dont specify a microverison negociates | |