| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-20 | |||
| 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? | |
| 14:50:13 | sean-k-mooney | im not sure if the code path that lands you there would result in that but no | |
| 14:50:19 | sean-k-mooney | not of the top of my head | |
| 14:50:50 | sean-k-mooney | allthough you are looking at the unit/func tests? | |
| 14:50:55 | sean-k-mooney | so we might just not have mocked it right | |
| 14:51:43 | sean-k-mooney | in real code it maight always be set but in our unit test it might not due to incorrect mocking maybe? | |
| 14:52:01 | gibi | it is tempest | |
| 14:52:09 | sean-k-mooney | fyi ill be afk for a while but ill update the spec when i get back | |
| 14:52:16 | gibi | sean-k-mooney: ack | |
| 14:52:22 | sean-k-mooney | ah ok ya i guess using testtool makes sense there | |
| 14:53:14 | sean-k-mooney | oh needed to exted time frame so its the min bandwith tests | |
| 14:53:18 | sean-k-mooney | weird | |
| 14:53:44 | gibi | I see in the api log that fault is lazy loaded | |
| 14:53:48 | gibi | for this request | |
| 14:54:00 | gibi | so somehow the fault is missing in the db | |
| 15:12:49 | lyarwood | https://review.opendev.org/c/openstack/nova/+/754702/ - there's a first, subnode deployment failed but we still tried to run multinode tests | |
| 15:44:04 | kashyap | Unrelated ... TIL, Red Hat announced gratis RHEL (you can now run upto 16 production instances): https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel | |
| 15:44:35 | kashyap | lyarwood: --^ Wonder if that allows one to start testing w/ proper RHEL in the upstream CI | |
| 15:45:56 | lyarwood | kashyap: I wouldn't expect it would no | |
| 15:46:24 | lyarwood | kashyap: and in any case testing RHEL in master CI seems a little pointless if we have centOS streams | |