)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":23567,"name":"Luis Tomas Bolivar","email":"ltomasbo@redhat.com","username":"ltomasbo"},"change_message_id":"5ee569d65f921522dba9af5f90b23ddbeb2965d7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6d40d220_d42ff989","updated":"2024-10-04 08:14:28.000000000","message":"LGTM, one question, would this block configuration of other flows in there by other entities? The idea here was to only remove the rules with our own cookies, in case there is another agent adding other rules.","commit_id":"d1be18d69ccf66ab0846a0ad4221806ad8420e68"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"087393cff839f3f4b76e8e5c4a3696443c06fc62","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"2111421d_1e935e5d","updated":"2024-09-03 15:02:50.000000000","message":"existing rules with different cookie values will be changed automatically, as the match line is similar.\n\nso effectively the cookie value is changes upon next sync and no manual changes are required when this patch is merged and deployed.","commit_id":"d1be18d69ccf66ab0846a0ad4221806ad8420e68"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"a62e2f0ff6bc0d3103a0e0057a74a1d3af0e2043","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"8793f6f8_a56558ca","in_reply_to":"6d40d220_d42ff989","updated":"2024-10-04 08:36:10.000000000","message":"No not to my knowledge, we just manage more cookie values, but leave the other cookie values alone (just like before)","commit_id":"d1be18d69ccf66ab0846a0ad4221806ad8420e68"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"a72c9e40fd5bd3601f8b66a71f0f04511890eb58","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"6eb7ddcd_631e9bdd","updated":"2024-10-04 12:12:20.000000000","message":"Since we do not meddle with other cookie values, there can be lingering rules if a provider network was deleted, as there will not be a vlandev available.\n\nNot sure how to fix that though, if that is something we want to fix.","commit_id":"ba34a3d7f80361dbb0cf72c12b8b0b44e7e6a4d4"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"d3204bde9ddda46b8658156bf4aa2f0278184b72","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"6fcd2429_252e3007","updated":"2025-01-21 14:04:56.000000000","message":"Makes sense, i also discovered another issue in our environment that i patched in.","commit_id":"8ab4a10ad8324e2c4ded5ec2c3fafce08bc2ac32"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"60eaff31d8a7c04c057c15c1aec33285d4172ff5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"a270debb_18f05e77","updated":"2025-02-13 16:51:25.000000000","message":"I\u0027m not 100% sure if this patch is involved or not, but we\u0027ve started seeing a weird behaviour around time of pulling it in.\n\nSo basically what we see, is that connection (ie SSH) returns back not via FIP, but via router ext gw (src nat):\nhttps://paste.openstack.org/show/bI63X2UOh12iRByvZB1e/\n\n`192.168.100.226` is the VM FIP\n` 192.168.100.249` is the router ext gw\n\nRolling back the patch though have broken connectivity at all, so as I said, not 100% sure, but it feels somehow related to this one","commit_id":"c6dda50fac7f319f60e9a7072ed80679875ff8b1"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"9daff43f4b502b4542545a1a3f85e2869db2c1e7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"5ec1ca8e_ca7278ba","updated":"2025-02-18 16:45:30.000000000","message":"Ok, we were able to reproduce the issue with NAT even without this patch, so sorry for bothering you and I think it looks quite fair and safe after all.","commit_id":"c6dda50fac7f319f60e9a7072ed80679875ff8b1"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"34bb0a193db36079d734cc5dd4afb8744234280e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"35d8bf5d_967bd999","updated":"2025-01-24 16:20:27.000000000","message":"recheck, i do not see yet how this is related to my change.","commit_id":"c6dda50fac7f319f60e9a7072ed80679875ff8b1"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"2b600490fc777a6669b302b12b8dc9bcb75d5f38","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":7,"id":"c75f8a61_5e705820","in_reply_to":"3717f9f3_d78adf52","updated":"2025-02-14 17:11:58.000000000","message":"Sure, we looked for MTU issues, though MTU won\u0027t cause messed up NAT rules ordering (ie - out from SNAT and not FIP).\n\nAnd no - internal connection worked nicely.\n\nI ended up flushing all OVS flows and reverting this patch - now I don\u0027t have any issues - neither performance nor connectivity wise.\n\nWhile I still can\u0027t confirm if it\u0027s directly related to the patch or some our other actions (after all it\u0027s a dev environment where we play with things), I\u0027d appreciate someone else to also test it out.\n\nI will apply this patch again, but we need to finalize some other things first, so it may take a week or so until I get back to it again. So good be to hold a bit with merging, if possible...","commit_id":"c6dda50fac7f319f60e9a7072ed80679875ff8b1"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"7395d3bd2a3e8f49199a8d28de7ffccea9e87b06","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"f74d8a60_739940ab","in_reply_to":"4aab42c8_12e83f71","updated":"2025-02-14 17:39:34.000000000","message":"TLDR: Would be nice to wait with merge of this one, as reverting back and cleaning up flows did solve the issue for us.\nI want to test it one more time, but have to complete tests of other things first (as there\u0027s internal time-constraints pressure to finalize ovn-bgp-agent implementation).","commit_id":"c6dda50fac7f319f60e9a7072ed80679875ff8b1"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"26da1277cef7019a7f7fb1e94c9369b393ab3c7f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"4aab42c8_12e83f71","in_reply_to":"58661661_600f202c","updated":"2025-02-14 17:23:36.000000000","message":"\u003e That it connects via the 169.254.31.31 ip not a bad thing\n\nI did tcpdump/ssh from inside of VRF to isolate everything that can happen after VRF. So connection via noop 169.254.31.31 is expected here. What is not expected - is reply from the router IP while connecting to VM via it\u0027s FIP.\n\nLike ping and telnet worked perfectly fine:\n```\n# ip vrf exec vrf-5001 telnet 192.168.100.226 22\nTrying 192.168.100.226...\nConnected to 192.168.100.226.\nEscape character is \u0027^]\u0027.\nSSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10\n\n# ip vrf exec vrf-5000 ping -c 1 -s 1472 -M do 192.168.100.226\nPING 192.168.100.226 (192.168.100.226) 1472(1500) bytes of data.\n1480 bytes from 192.168.100.226: icmp_seq\u003d1 ttl\u003d59 time\u003d0.846 ms\n\n--- 192.168.100.226 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev \u003d 0.846/0.846/0.846/0.000 ms\n```\n\n\u003e Assuming that the vm is hosted on another host\n\nSo eventually we have a usecase with net nodes, where ovn-gateways are a completely different set of hosts, then nova-compute ones.\nSo nova-computes are not having FRR/ovn-bgp-agent/vxlans/distributed FIP/etc","commit_id":"c6dda50fac7f319f60e9a7072ed80679875ff8b1"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"3316256e38036eab67c196c6dd8d262397617083","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"79b9171b_b8608606","in_reply_to":"5ec1ca8e_ca7278ba","updated":"2025-02-19 09:28:34.000000000","message":"Thanks for letting us know!","commit_id":"c6dda50fac7f319f60e9a7072ed80679875ff8b1"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"87863992adeb160c1f51ab058d7a627850367782","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"963609d8_e7c6bfc2","in_reply_to":"79b9171b_b8608606","updated":"2025-02-21 14:47:16.000000000","message":"We found the issue actually, so I will share it here.\n\nWe pinpointed this to setting `ovn_router_indirect_snat \u003d True` and the absence of the change: https://patchwork.ozlabs.org/project/ovn/patch/20240827085252.458355-1-amusil@redhat.com/\n\nSo after 3-step tcp handshake, IP was switched from FIP to SRC nat one, breaking SRC-DST nat.","commit_id":"c6dda50fac7f319f60e9a7072ed80679875ff8b1"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"678baa49b5e78c1bed5158ea5f4aa83f38c5c75a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"3717f9f3_d78adf52","in_reply_to":"a270debb_18f05e77","updated":"2025-02-14 08:06:12.000000000","message":"I doubt indeed it is this patch, (as it will make sure the flows will remain in ovs-ofctl) also because your tcp dump shows that there is connection possible (it says connected, but fails in the handshake part of ssh), so there is some form of connectivity at least, which rules out the routing part that ovn-bgp-agent provides. That it connects via the 169.254.31.31 ip not a bad thing, as long as the vm has a default gateway it will just work fine, assuming it can resolve the gateway ip; which it can otherwise it would not be able to get a connection).\n\nI\u0027d search for MTU issues and do tcpdump on the tap interface of the VM as well, to see if there are more packets lost. Do you also see this behaviour on internal traffic (e.g. from one vm to another vm in the same network)?\n\nAssuming that the vm is hosted on another port, try and do a tcpdump of the vxlan traffic between your host and the host where the vm runs on, maybe that will tell some story as to why it is not working.\n\nit could be so many things unfortunately, that it is hard to point out what could be the issue on your end (have you checked your iptables everywhere?).","commit_id":"c6dda50fac7f319f60e9a7072ed80679875ff8b1"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"04fbb39b01c4d9dabd2b7c59b16cb21e6d8fa285","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":7,"id":"58661661_600f202c","in_reply_to":"c75f8a61_5e705820","updated":"2025-02-14 17:13:51.000000000","message":"A bit more context - for getting from \"working\" to really broken state was applying these 3 patches:\n* https://review.opendev.org/c/openstack/ovn-bgp-agent/+/940132\n* https://review.opendev.org/c/openstack/ovn-bgp-agent/+/927816\n* https://review.opendev.org/c/openstack/ovn-bgp-agent/+/927791\n\nBut I see only this one messing up with flows, which theoretically can at least be somehow related. Not confirming it is, but others looks too harmless.","commit_id":"c6dda50fac7f319f60e9a7072ed80679875ff8b1"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"c825ede3fb079be16fa39efa1d66e26c872f1c28","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"319be909_81b5c953","updated":"2025-02-25 12:34:56.000000000","message":"One fix included to reset the _in_port variable upon disconnect. Once it connects again, it might get another in_port for the patch.","commit_id":"2d8a7ef7cd44580e3383830f928659f709f47085"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"fe78dcca1864889e29d78742339ff84093bc5e26","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"906aab69_d1835e52","updated":"2025-11-28 16:48:24.000000000","message":"@libosvar@redhat.com would be nice if we could have a review of this one","commit_id":"e37e75dbbe7ac1e6106a7ee75c53a88cc4974368"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"91af69b9894b38d711cb5a8a2dfc91c99e56ccd7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"19440710_5a6e0b19","updated":"2026-02-06 13:00:46.000000000","message":"My apologies it took so long to review this :) Some small comments","commit_id":"e37e75dbbe7ac1e6106a7ee75c53a88cc4974368"}],"ovn_bgp_agent/drivers/openstack/utils/evpn.py":[{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"435a9c5dc7018e3431c476e1c303899e3d8025c3","unresolved":true,"context_lines":[{"line_number":195,"context_line":"            in_port \u003d ovs.get_ovs_patch_port_ofport(self.port.name)"},{"line_number":196,"context_line":"            LOG.debug(\u0027ovs in-port: %s\u0027, in_port)"},{"line_number":197,"context_line":"            return in_port"},{"line_number":198,"context_line":"        except Exception:"},{"line_number":199,"context_line":"            LOG.error(\u0027Unable to find in-port for port %s\u0027, self.port.name)"},{"line_number":200,"context_line":"            return False"},{"line_number":201,"context_line":""},{"line_number":202,"context_line":"    @property"},{"line_number":203,"context_line":"    def ovs_cookie(self) -\u003e str:"}],"source_content_type":"text/x-python","patch_set":5,"id":"4ca9bbc0_49b101b1","line":200,"range":{"start_line":198,"start_character":0,"end_line":200,"end_character":24},"updated":"2024-10-09 17:55:52.000000000","message":"It would be better to leave the exception bubble up to where the error handling is done. Returning False here makes it confusing that the property sometimes returns in_port and some other type. It then requires to check this condition multiple times - on L285 and L273.","commit_id":"d76d720e00ed963edb658575d626263f965380cd"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"d3204bde9ddda46b8658156bf4aa2f0278184b72","unresolved":false,"context_lines":[{"line_number":195,"context_line":"            in_port \u003d ovs.get_ovs_patch_port_ofport(self.port.name)"},{"line_number":196,"context_line":"            LOG.debug(\u0027ovs in-port: %s\u0027, in_port)"},{"line_number":197,"context_line":"            return in_port"},{"line_number":198,"context_line":"        except Exception:"},{"line_number":199,"context_line":"            LOG.error(\u0027Unable to find in-port for port %s\u0027, self.port.name)"},{"line_number":200,"context_line":"            return False"},{"line_number":201,"context_line":""},{"line_number":202,"context_line":"    @property"},{"line_number":203,"context_line":"    def ovs_cookie(self) -\u003e str:"}],"source_content_type":"text/x-python","patch_set":5,"id":"8275f83c_3737bc12","line":200,"range":{"start_line":198,"start_character":0,"end_line":200,"end_character":24},"in_reply_to":"4ca9bbc0_49b101b1","updated":"2025-01-21 14:04:56.000000000","message":"Done","commit_id":"d76d720e00ed963edb658575d626263f965380cd"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"f5941426f883daec0ba2820e9953967b131f82fb","unresolved":true,"context_lines":[{"line_number":196,"context_line":"            self._lladdr \u003d linux_net.get_interface_address(self.veth_vrf)"},{"line_number":197,"context_line":"        return self._lladdr"},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"    @property"},{"line_number":200,"context_line":"    def in_port(self):"},{"line_number":201,"context_line":"        # Cache the in_port for this vlan, as it will not change and we need"},{"line_number":202,"context_line":"        # it for the disconnect action."},{"line_number":203,"context_line":"        if self._in_port is None:"},{"line_number":204,"context_line":"            self._in_port \u003d ovs.get_ovs_patch_port_ofport(self.port.name)"},{"line_number":205,"context_line":"            LOG.debug(\"ovs in-port: %s\", self._in_port)"},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"        return self._in_port"},{"line_number":208,"context_line":""}],"source_content_type":"text/x-python","patch_set":9,"id":"8eedf3f9_7b30259b","line":205,"range":{"start_line":199,"start_character":0,"end_line":205,"end_character":55},"updated":"2026-02-06 13:00:16.000000000","message":"What\u0027s the benefit of caching here? The ofport number is stored in the local ovsdb replica in memory, so both caching and the lookup in OVS is just a reading from local memory.\n\nWith that you get rid of complexity in keeping the `_in_port` attribute consistent as you\u0027ll always get the right value.\n\nI\u0027d suggest to change it to just\n```\n@property\ndef in_port(self):\n    return ovs.get_ovs_patch_port_ofport(self.port.name)\n```","commit_id":"e37e75dbbe7ac1e6106a7ee75c53a88cc4974368"}],"ovn_bgp_agent/drivers/openstack/utils/wire.py":[{"author":{"_account_id":23567,"name":"Luis Tomas Bolivar","email":"ltomasbo@redhat.com","username":"ltomasbo"},"change_message_id":"adad9241ffb7520ba98c57ca6b720c72122bea36","unresolved":true,"context_lines":[{"line_number":567,"context_line":"        for flow in flows:"},{"line_number":568,"context_line":"            # \u0027 cookie\u003d0x3e7, duration\u003d0s, table\u003d0, .... actions\u003dNORMAL\u0027"},{"line_number":569,"context_line":"            flow_cookie \u003d flow.strip().split(\u0027,\u0027)[0].split(\u0027\u003d\u0027)[1]"},{"line_number":570,"context_line":"            if flow_cookie not in cookies:"},{"line_number":571,"context_line":"                LOG.info(\u0027Delete excessive flow %s\u0027, flow)"},{"line_number":572,"context_line":"                ovs.del_flow(flow, bridge, flow_cookie)"},{"line_number":573,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"c03eb5c5_9fa8b046","line":570,"range":{"start_line":570,"start_character":1,"end_line":570,"end_character":42},"updated":"2024-10-04 08:52:14.000000000","message":"wouldn´t this block remove all the flows whose cookie is not in the allowed_cookies? \nI think this may need to remove only the flows that have a matching cookie, without the suffix, i,e., removing all the flows whose cookie start with OVS_COOKIE constant","commit_id":"d1be18d69ccf66ab0846a0ad4221806ad8420e68"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"d3204bde9ddda46b8658156bf4aa2f0278184b72","unresolved":false,"context_lines":[{"line_number":567,"context_line":"        for flow in flows:"},{"line_number":568,"context_line":"            # \u0027 cookie\u003d0x3e7, duration\u003d0s, table\u003d0, .... actions\u003dNORMAL\u0027"},{"line_number":569,"context_line":"            flow_cookie \u003d flow.strip().split(\u0027,\u0027)[0].split(\u0027\u003d\u0027)[1]"},{"line_number":570,"context_line":"            if flow_cookie not in cookies:"},{"line_number":571,"context_line":"                LOG.info(\u0027Delete excessive flow %s\u0027, flow)"},{"line_number":572,"context_line":"                ovs.del_flow(flow, bridge, flow_cookie)"},{"line_number":573,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"88b44a4a_118c6fe3","line":570,"range":{"start_line":570,"start_character":1,"end_line":570,"end_character":42},"in_reply_to":"369dc712_add6be22","updated":"2025-01-21 14:04:56.000000000","message":"Done","commit_id":"d1be18d69ccf66ab0846a0ad4221806ad8420e68"},{"author":{"_account_id":25468,"name":"Michel Nederlof","email":"michel@nederlof.info","username":"pellucid"},"change_message_id":"952ed447e065491268fbbb1568df50a1efc87887","unresolved":true,"context_lines":[{"line_number":567,"context_line":"        for flow in flows:"},{"line_number":568,"context_line":"            # \u0027 cookie\u003d0x3e7, duration\u003d0s, table\u003d0, .... actions\u003dNORMAL\u0027"},{"line_number":569,"context_line":"            flow_cookie \u003d flow.strip().split(\u0027,\u0027)[0].split(\u0027\u003d\u0027)[1]"},{"line_number":570,"context_line":"            if flow_cookie not in cookies:"},{"line_number":571,"context_line":"                LOG.info(\u0027Delete excessive flow %s\u0027, flow)"},{"line_number":572,"context_line":"                ovs.del_flow(flow, bridge, flow_cookie)"},{"line_number":573,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"369dc712_add6be22","line":570,"range":{"start_line":570,"start_character":1,"end_line":570,"end_character":42},"in_reply_to":"c03eb5c5_9fa8b046","updated":"2024-10-04 09:44:13.000000000","message":"Hmm yes, you might be on to something here.. 😄\n\nI will see if i can work on another approach.","commit_id":"d1be18d69ccf66ab0846a0ad4221806ad8420e68"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"f5941426f883daec0ba2820e9953967b131f82fb","unresolved":true,"context_lines":[{"line_number":618,"context_line":"                )"},{"line_number":619,"context_line":"            else:"},{"line_number":620,"context_line":"                ovs_bridge \u003d evpn_bridge.ovs_bridge"},{"line_number":621,"context_line":"                alist \u003d inactive_cookies.setdefault(ovs_bridge, [])"},{"line_number":622,"context_line":"                alist.append(vlan_dev.ovs_cookie)  # string number value"},{"line_number":623,"context_line":"                alist.append(str(hex(int(vlan_dev.ovs_cookie))))  # hex value"},{"line_number":624,"context_line":""}],"source_content_type":"text/x-python","patch_set":9,"id":"8ada49a7_5232b0fa","line":621,"range":{"start_line":621,"start_character":64,"end_line":621,"end_character":66},"updated":"2026-02-06 13:00:16.000000000","message":"Would a `set()` make more sense here?","commit_id":"e37e75dbbe7ac1e6106a7ee75c53a88cc4974368"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"f5941426f883daec0ba2820e9953967b131f82fb","unresolved":true,"context_lines":[{"line_number":626,"context_line":"    for bridge, cookies in inactive_cookies.items():"},{"line_number":627,"context_line":"        flows \u003d ovs.get_bridge_flows(bridge)"},{"line_number":628,"context_line":"        for flow in flows:"},{"line_number":629,"context_line":"            # \u0027 cookie\u003d0x3e7, duration\u003d0s, table\u003d0, .... actions\u003dNORMAL\u0027"},{"line_number":630,"context_line":"            if \u0027cookie\u003d\u0027 not in flow:"},{"line_number":631,"context_line":"                continue"},{"line_number":632,"context_line":"            flow_cookie \u003d flow.strip().split(\u0027,\u0027)[0].split(\u0027\u003d\u0027)[1]"},{"line_number":633,"context_line":"            if flow_cookie in cookies:"},{"line_number":634,"context_line":"                LOG.info(\u0027Remove inactive flow %s\u0027, flow)"},{"line_number":635,"context_line":"                ovs.del_flow(flow, bridge, flow_cookie)"}],"source_content_type":"text/x-python","patch_set":9,"id":"c5b0b1bb_bad09a62","line":632,"range":{"start_line":629,"start_character":0,"end_line":632,"end_character":66},"updated":"2026-02-06 13:00:16.000000000","message":"Better to use a regular expression to extract the cookie from the flow string.","commit_id":"e37e75dbbe7ac1e6106a7ee75c53a88cc4974368"}]}