)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"aa1a8fc0ea47adf783a72eb94c7bcd1e797c9925","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"78d4cf26_9ea0b4bc","updated":"2022-08-30 11:18:54.000000000","message":"Is this related to our last drivers meeting discussion (see [1]), if yes see the logs, perhaps can help to understand what could be the next step, but my crystal ball shows me a PTG x-project discussion.\n\n[1]: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-08-26-14.00.log.html#l-53","commit_id":"81a1ff6120a9ef48b7892b19355c0971ebc54076"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3b829be6e8b5ea81f1c1629b77a658fdb4104e14","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"255196a7_5aaf2d58","updated":"2022-08-30 11:52:54.000000000","message":"i dont really intend this to be merged this is more to track the discussion of how to move forward to fix the regression intoduced by the orginal fix.\n\nIMO that should not have been merged or backported as it was a breaking api change.\n","commit_id":"81a1ff6120a9ef48b7892b19355c0971ebc54076"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0941ab9e6d0f07df3c20f680cf1c3c77becfdbf4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a457fc2f_1822f8d1","updated":"2022-08-26 15:06:25.000000000","message":"this woudl be one path forward to adress the regression\n\nalthough the path forward i would prefer to take i think is for nova to provide this information automatically. that would requrie use to detecht this capablity.\nstash it in the exta_info colume of the pci_devices table and then populate it in the port profile when we set the pci_slot.\n\n\nthat would actully make this check userful in neutron but as it stands today its more hameful then userful as it does nto check what we thing it does.\n\nits just checik in f a string is set in the port and has no actual baring on if the vf select by nova actully is from hardware offloed ovs.\n","commit_id":"81a1ff6120a9ef48b7892b19355c0971ebc54076"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"0815d2d5393e9c1f93ce5da475430ba1e2b0b680","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6bcd0953_6fada490","in_reply_to":"255196a7_5aaf2d58","updated":"2022-08-31 09:22:17.000000000","message":"I added a topic for the PTG: https://etherpad.opendev.org/p/neutron-antelope-ptg#L86 , please add more background under it if you think it is a good idea to have such discussion or remove it completely.","commit_id":"81a1ff6120a9ef48b7892b19355c0971ebc54076"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3b829be6e8b5ea81f1c1629b77a658fdb4104e14","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"5c652eb0_8d6f7784","in_reply_to":"3a2527b5_87bfc48c","updated":"2022-08-30 11:52:54.000000000","message":"no neuton has not change reverting this would reintoduce the inablity to have hardware offloaded ovs and the sriov nic agent on the same host.\n\nhowever with this change inplace it menas non admins cannot safely use this feature at all.\n\nin our downstream product it had to be worked around using custom policy btu that has security impacts that i am not happy supporting going forward.\n\nwhile its unlikely we will revert hardwar offload ovs supprot back to tech preview at this point if i had been aware of this patch when the graduation to full supprot was being discsed internally i would have seen this as a blocker to full support.\n\nso its imporant we fix this properly and securly going forward.\n\nalthough as i noted in comment 1\nhttps://bugs.launchpad.net/neutron/+bug/1713590/comments/1\n\nthe way to fix this without a code change was simply to change the order of the ml2 drivers\n\nmechanism_drivers \u003d sriovnicswitch,openvswitch\n\nthat would allow the sriov nic agent to prefercally try and bind any VF/PF first and wehn that failed for the ovs offload port its would fallback to the ovs ml2 dirver.","commit_id":"81a1ff6120a9ef48b7892b19355c0971ebc54076"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3b829be6e8b5ea81f1c1629b77a658fdb4104e14","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b30142d0_773d1eb3","in_reply_to":"78d4cf26_9ea0b4bc","updated":"2022-08-30 11:52:54.000000000","message":"yes it is.\n\nwe basicaly have two paths forward.\n\nwe revert  change so that neutron doe not filter.\n\nas noted in my responce to moshe that would reintoduce the bug the orginal patch tried to fix but it would fix the regression that was intoduced which resulting in hardware offloaed ovs being admin only.\n\n\nthe much better approch is for nova to simpley discover the swtichdev capableity and set it in the binding:profile.\nThis would be a nova only change.\n\naddtionally we could add the ablity to request hardware offloaed ovs via a neutron extentions.\n\nif we are to do this rahter then enabel that usecase directly i would instead condier a way to support some generic way of requesting traits.\n\nwe are currently finsihing adding pci device in placment support to nova for non nueton pci devices.\n\ni.e. for anything that is  not a nic.\n\nnext cycel depending on capsity we would liek to figure out how to make this work for neutron ports too.\n\nwe have a rough outline of how that should work but there are still details to be resoveld. so perhapse we can simply capture the how to schduler to host with hardware offloed ovs into that discussion.","commit_id":"81a1ff6120a9ef48b7892b19355c0971ebc54076"},{"author":{"_account_id":12171,"name":"Moshe Levi","email":"moshele@nvidia.com","username":"moshele"},"change_message_id":"df900946970f59f1ea63193e447547a5425c8062","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"3a2527b5_87bfc48c","in_reply_to":"a457fc2f_1822f8d1","updated":"2022-08-29 21:48:25.000000000","message":"Maybe neutron code has changed, but when this patch merged was to solve running ovs mech with Normal port and sriovnicsiwtch with direct port. if you create VM with direct port the mechanism driver which will pick to do the binding will be according to the mechanism driver list. So if you have ovs, sriovnicsiwtch. The ovs will try to bind it instead of the sriovnicsiwtch (assuming you use SR-IOV legacy). \n\nThe bug was opened by redhat [1] so revert it may cause regression break. (assuming neutron binding logic hasn\u0027t changed)  \n\nI think nova adding the switchdev capability is better approach. \n\n[1] - https://bugs.launchpad.net/neutron/+bug/1713590","commit_id":"81a1ff6120a9ef48b7892b19355c0971ebc54076"}]}