| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-20 | |||
| 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 | |
| 14:31:00 | sean-k-mooney | if you explcitly use latest i dont no if it blindly uses it like osc or does negociation | |
| 14:31:31 | sean-k-mooney | at the api level i think its an alias for the latest microverion in nova | |
| 14:31:41 | sean-k-mooney | but that is not a stardard part of microverions | |
| 14:32:29 | sean-k-mooney | if you use latest the behavior will change between cloud or after upgrades so generally you sould not use it unless you are manually using clients to do something | |
| 14:32:43 | sean-k-mooney | e.g. if this is used in code somewhere you shoudl not use latest | |
| 14:33:02 | sean-k-mooney | you should use the minium microverion for the feature you are using | |
| 14:33:36 | sean-k-mooney | that is what nova and other service do internally when calling each other | |
| 14:36:37 | nightmare_unreal | I see | |
| 14:36:42 | nightmare_unreal | thanks for explanation | |
| 14:37:20 | sean-k-mooney | i assume you were using the openstack client when you said placment was defaulting to 1.0 | |
| 14:39:18 | sean-k-mooney | osc does not do microverion negocation to provide a stable striptable unifrom inteface. some plugins like ironic disagree with that philosocy and implemented negoication themselves but that was inteionally not done osc itself | |
| 14:40:06 | sean-k-mooney | the placment team did like the osc phioscophy so intentionlly did not implment microverion negociation in there placment plugin | |
| 14:45:47 | 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 | |
| 14:47:35 | gibi | hm, does somebody has an idea how can it be that a server in ERROR state does not have a fault field? http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22testtools.matchers._impl.MismatchError%3A%20'fault'%20not%20in%20%7B%5C%22 | |
| 14:49:55 | sean-k-mooney | um is it in cell0? | |