)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"031e76a0a63b009267721f0079a3272117cbc6f5","unresolved":false,"context_lines":[{"line_number":11,"context_line":"drop these packets, because they cannot match any flow in"},{"line_number":12,"context_line":"high priority(65 70 80 95), only the priority 10 flow can"},{"line_number":13,"context_line":"match them, and its aciton is drop, so all the rarp packets"},{"line_number":14,"context_line":"will be dropped, and the connectivity will be broken after"},{"line_number":15,"context_line":"live-migration."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Change-Id: Id1cc34f0f544b2cb8cc89af2cb81bb15e4605a0e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"bfb3d3c7_08d2b128","line":14,"range":{"start_line":14,"start_character":25,"end_line":14,"end_character":52},"updated":"2019-05-31 14:41:18.000000000","message":"So it is is a momentary down time, and it will recover due to the network-vif-pluged notification, right?\n\nBut according to your comment here:\nhttps://bugs.launchpad.net/neutron/+bug/1414559/comments/50\n\nYou are using the virsh command to live-migrate the instance, so IMO, neutron and nova will have no idea about this transition. The data plane will be down forever in your case?","commit_id":"5ce64815de9b8fa71ceda8297cbe6d940a3b53b9"},{"author":{"_account_id":19956,"name":"Yang Li","email":"yang.li@easystack.cn","username":"leonstack"},"change_message_id":"c16764e36eeff1722505218e53ced47541d35032","unresolved":false,"context_lines":[{"line_number":11,"context_line":"drop these packets, because they cannot match any flow in"},{"line_number":12,"context_line":"high priority(65 70 80 95), only the priority 10 flow can"},{"line_number":13,"context_line":"match them, and its aciton is drop, so all the rarp packets"},{"line_number":14,"context_line":"will be dropped, and the connectivity will be broken after"},{"line_number":15,"context_line":"live-migration."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Change-Id: Id1cc34f0f544b2cb8cc89af2cb81bb15e4605a0e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"bfb3d3c7_236a3619","line":14,"range":{"start_line":14,"start_character":25,"end_line":14,"end_character":52},"in_reply_to":"bfb3d3c7_08d2b128","updated":"2019-05-31 15:09:21.000000000","message":"Actually the connectivity won\u0027t recover immediately even nova get network-vif-pluged, because the rarp packet wasn\u0027t sent out, the MAC learning still cannot be triggered, it will wait for a short time to recover.\nAnd virsh command can trigger the event too, because when the tap was created, the neutron will catch the event(monitored by ovsdb-client), and update openflow and tag for this device, and then sent a network-vif-pluged event to nova, so with this patch the data won\u0027t be down anytime, but without this patch, it may down for a little time(5~40s mostly)","commit_id":"5ce64815de9b8fa71ceda8297cbe6d940a3b53b9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9c175cb82ef174131e3242a01d26b2a9e0eb48fa","unresolved":false,"context_lines":[{"line_number":11,"context_line":"drop these packets, because they cannot match any flow in"},{"line_number":12,"context_line":"high priority(65 70 80 95), only the priority 10 flow can"},{"line_number":13,"context_line":"match them, and its aciton is drop, so all the rarp packets"},{"line_number":14,"context_line":"will be dropped, and the connectivity will be broken after"},{"line_number":15,"context_line":"live-migration."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Change-Id: Id1cc34f0f544b2cb8cc89af2cb81bb15e4605a0e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"9fb8cfa7_0d2155a0","line":14,"range":{"start_line":14,"start_character":25,"end_line":14,"end_character":52},"in_reply_to":"bfb3d3c7_236a3619","updated":"2019-05-31 17:30:15.000000000","message":"so i dont think this will actully work based on my previous coment on ps1 \nhttps://review.opendev.org/#/c/661921/1/neutron/agent/linux/openvswitch_firewall/firewall.py@815\n\nther e is a race where the RARP packets will be sent before neutron has move the port to the correct vlan.\n\ni have resotred https://review.opendev.org/#/c/640258/\n\nand should have time to start reworking it next week.\nwhen combinded with https://review.opendev.org/#/c/602432\nthat should fix this issue.\n\nthe rarp packets should hit the normal action rule if the port is on the correct internal vlan.","commit_id":"5ce64815de9b8fa71ceda8297cbe6d940a3b53b9"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"031e76a0a63b009267721f0079a3272117cbc6f5","unresolved":false,"context_lines":[{"line_number":15,"context_line":"live-migration."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Change-Id: Id1cc34f0f544b2cb8cc89af2cb81bb15e4605a0e"},{"line_number":18,"context_line":"Partial-Bug: #1414559"},{"line_number":19,"context_line":"See-Also: https://review.openstack.org/661938 (neutron spec)"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"bfb3d3c7_8886a165","line":18,"range":{"start_line":18,"start_character":0,"end_line":18,"end_character":21},"updated":"2019-05-31 14:41:18.000000000","message":"Please file a new bug for this patch, this bug was marked as fixed and it was really a long time ago when there was no openflow firewall. So let\u0027s track this as a new issue.","commit_id":"5ce64815de9b8fa71ceda8297cbe6d940a3b53b9"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"371584ec434980c2d607b80a46edd200075b4fad","unresolved":true,"context_lines":[{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Change-Id: Id1cc34f0f544b2cb8cc89af2cb81bb15e4605a0e"},{"line_number":18,"context_line":"Partial-Bug: #1831404"},{"line_number":19,"context_line":"Depends-On: https://review.openstack.org/661938"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":8,"id":"ee2feee5_69f1634a","line":19,"updated":"2023-01-24 15:11:00.000000000","message":"nit: This can be removed since it has merged","commit_id":"6bb36aa50e57853e79288a1e5d0cdef283a9abc5"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"371584ec434980c2d607b80a46edd200075b4fad","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"857108c1_d461e97e","updated":"2023-01-24 15:11:00.000000000","message":"Should be able to rebase this to latest master change since the neutron-lib I\u0027m sure has been released by now.","commit_id":"6bb36aa50e57853e79288a1e5d0cdef283a9abc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e9582402788e8f1beb8feb3c840991722bd9dde8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"a654f2c2_e5db7173","updated":"2023-12-05 09:15:27.000000000","message":"@rodolfo your comments were adressed by the way.\nthe neutron lib bump happend 4 years ago so if you can re reivew i think the reason for your -1 nolonger applies and we can proceed with merging this now.","commit_id":"5c246e6b578cda9e051f8a36b9b1687963e8aeb0"},{"author":{"_account_id":5948,"name":"Oleg Bondarev","email":"obondarev@mirantis.com","username":"obondarev"},"change_message_id":"c98cda298bdfa17399bf93182d5e5ddf36a29a88","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"00c2c743_664873c4","updated":"2023-02-15 07:29:11.000000000","message":"Good catch!","commit_id":"5c246e6b578cda9e051f8a36b9b1687963e8aeb0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"bd936476780a1310720145043b24f464b4875c96","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"3bb9762d_13a290c2","updated":"2023-12-05 09:13:52.000000000","message":"im honestly kind of surpised this is still open.\ni litrally tought this was fixed 4 years ago so yes we should fix this.\nthis is a regression between the iptable driver and ovs driver.","commit_id":"5c246e6b578cda9e051f8a36b9b1687963e8aeb0"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"995cd2b47ee5c9eb285ecb812320aad7b186b5c5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"5474aa81_c87b16b5","updated":"2023-12-01 18:31:02.000000000","message":"recheck get new zuul logs","commit_id":"5c246e6b578cda9e051f8a36b9b1687963e8aeb0"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"a9c10267615a8c7a2c41ba44e5bebfbf815c2aaf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"ea401210_69364f7e","updated":"2023-02-15 01:44:04.000000000","message":"recheck infra failure","commit_id":"5c246e6b578cda9e051f8a36b9b1687963e8aeb0"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"9d8559b51713a44609480667381639d32b46331a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"5ea37cc5_d392d1a3","updated":"2023-12-01 21:09:34.000000000","message":"recheck unrelated ovsdbapp failure","commit_id":"5c246e6b578cda9e051f8a36b9b1687963e8aeb0"}],"neutron/agent/linux/openvswitch_firewall/firewall.py":[{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"c99e517da87680f16fdc331141e186a8c793e17e","unresolved":false,"context_lines":[{"line_number":812,"context_line":"            )"},{"line_number":813,"context_line":"            self._add_flow("},{"line_number":814,"context_line":"                table\u003dovs_consts.BASE_EGRESS_TABLE,"},{"line_number":815,"context_line":"                priority\u003d95,"},{"line_number":816,"context_line":"                reg_port\u003dport.ofport,"},{"line_number":817,"context_line":"                ct_state\u003dovsfw_consts.OF_STATE_NOT_TRACKED,"},{"line_number":818,"context_line":"                dl_type\u003dlib_const.ETHERTYPE_RARP,"}],"source_content_type":"text/x-python","patch_set":1,"id":"bfb3d3c7_e0b44af4","line":815,"updated":"2019-05-29 10:20:20.000000000","message":"1) You\u0027ll need to modify the unit tests.\n2) This patch doesn\u0027t exactly match the bug description. IMO, this is another problem related to the firewall and not to QEMU.\n3) You need to add this rule to the _initialize_ingress, if you want to receive the packets back.","commit_id":"8a5c3db76eaf9010b1c85915c4332c757562ce64"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"556ed8543855cf90568ff70ca956bfb09f400c00","unresolved":false,"context_lines":[{"line_number":812,"context_line":"            )"},{"line_number":813,"context_line":"            self._add_flow("},{"line_number":814,"context_line":"                table\u003dovs_consts.BASE_EGRESS_TABLE,"},{"line_number":815,"context_line":"                priority\u003d95,"},{"line_number":816,"context_line":"                reg_port\u003dport.ofport,"},{"line_number":817,"context_line":"                ct_state\u003dovsfw_consts.OF_STATE_NOT_TRACKED,"},{"line_number":818,"context_line":"                dl_type\u003dlib_const.ETHERTYPE_RARP,"}],"source_content_type":"text/x-python","patch_set":1,"id":"bfb3d3c7_c6c35e88","line":815,"in_reply_to":"bfb3d3c7_e0b44af4","updated":"2019-05-29 11:36:06.000000000","message":"the original problem is caused becaue there is a race between libvirt adding the port to ovs and the l2 agent adding the vlan tage to put it on the correct neutron netwrok so that the maclarning tables can be updated by the RARP packets.\n\ni dont see how this will help as the RARP packets will not be \ntagged correctly so they wont be sent on the correct neutron network.","commit_id":"8a5c3db76eaf9010b1c85915c4332c757562ce64"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"031e76a0a63b009267721f0079a3272117cbc6f5","unresolved":false,"context_lines":[{"line_number":816,"context_line":"                reg_port\u003dport.ofport,"},{"line_number":817,"context_line":"                dl_type\u003dlib_const.ETHERTYPE_RARP,"},{"line_number":818,"context_line":"                in_port\u003dport.ofport,"},{"line_number":819,"context_line":"                dl_src\u003dmac_addr,"},{"line_number":820,"context_line":"                actions\u003d\u0027resubmit(,%d)\u0027 % ("},{"line_number":821,"context_line":"                    ovs_consts.ACCEPTED_EGRESS_TRAFFIC_NORMAL_TABLE)"},{"line_number":822,"context_line":"            )"}],"source_content_type":"text/x-python","patch_set":4,"id":"bfb3d3c7_a89a8510","line":819,"range":{"start_line":819,"start_character":23,"end_line":819,"end_character":31},"updated":"2019-05-31 14:41:18.000000000","message":"So, this is to add rules for port allowed_pairs, not the port mac itself, so this rule will be matched?\n\nAnd, we should be very cautious about such broadcast packages, because it may be easily to cause cluster transmission pressures, or malicious attacks send out from these flows.","commit_id":"5ce64815de9b8fa71ceda8297cbe6d940a3b53b9"}]}