)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"c49b38a6a1a267799bdd263dcb42e86539c57b95","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e6d89066_a9e04cb4","updated":"2024-05-01 23:23:56.000000000","message":"The other possible solution using 0.0.0.0/0","commit_id":"19d74a1f832decdfa7cd8b84544e44e50a717821"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"0bdf8fe63544d714a46ab0c8ed55d8f4788cd880","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"64becdac_e525346a","updated":"2024-08-17 04:01:08.000000000","message":"FYI reviving this work here: https://review.opendev.org/c/openstack/neutron/+/926495 (WIP for now until we confirm OVN fixes the issues with 0.0.0.0/0 nat).","commit_id":"0630d1b60b3091ddd0fc7afd9e5f0521a7327bd3"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"daa803ee58642a23297ce22cb099d3ae2cabd4c6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"5e10f86a_72090a9e","updated":"2024-08-15 16:46:38.000000000","message":"FYI we may want to restore this one if OVN fixes 0.0.0.0/0 snat records handling with FIPs. We are working with OVN team to resolve the issue there.\n\nhttps://issues.redhat.com/browse/FDP-744","commit_id":"0630d1b60b3091ddd0fc7afd9e5f0521a7327bd3"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"d768dfcf5ca80737c59002f697c1393ebf8f7da0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ec477d39_b5c0f06a","updated":"2024-05-03 19:05:09.000000000","message":"I confirmed the two test failures are due to this patch, still debugging.","commit_id":"0630d1b60b3091ddd0fc7afd9e5f0521a7327bd3"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"d74af14a0d1f21f1deae3509062942c425a8f3b9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f34358cb_8020a0c4","updated":"2024-05-06 21:39:01.000000000","message":"Just adding some debugging notes. Looking at this test first.\n\ntest_reuse_ip_address_with_other_fip_on_other_router()\n\n        \"\"\"Reuse IP address by another floating IP on another router\n\n        Scenario:\n            1. Create and connect a router to the external network.\n            2. Create and connect an internal network to the router.\n            3. Create and connect 2 VMs to the internal network.\n            4. Create FIPs in the external network for the VMs.\n            5. Make sure that VM1 can ping VM2 FIP address.\n            6. Create and connect one more router to the external network.\n            7. Create and connect an internal network to the second router.\n            8. Create and connect a VM (VM3) to the internal network of\n               the second router.\n            9. Delete VM2 FIP but save IP address that it used. The FIP is\n               deleted just before the creation of the new IP to \"reserve\" the\n               IP address associated (see LP#1880976).\n            10. Create a FIP for the VM3 in the external network with\n                the same IP address that was used for VM2.\n            11. Make sure that now VM1 is able to reach VM3 using the FIP.\n\nUsing real VMs this fails at Step #5 (Make sure that VM1 can ping VM2 FIP address)\n\nTcpdump does at least show the same in/out packets on the external interfaces with my change applied, but inside the VM there is no reply seen.\n\nAnd dumping the flows shows the same entries for anything related to the FIPs.\n\nI wonder if there is something in conntrack affecting this?","commit_id":"0630d1b60b3091ddd0fc7afd9e5f0521a7327bd3"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"7c463b0fe83d15c7a199302d4ba291d768b2d33b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"50242074_6cd3b5ca","updated":"2024-05-02 22:00:49.000000000","message":"recheck LogicalSwitchPortUpdateLogicalRouterPortEvent failure, which I see in other changes as well","commit_id":"0630d1b60b3091ddd0fc7afd9e5f0521a7327bd3"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"9de0286114c3338519ee20d717af56af5e0ba6a9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f3895a4c_d92a4d8c","updated":"2024-05-03 13:09:07.000000000","message":"recheck unrelated test failure","commit_id":"0630d1b60b3091ddd0fc7afd9e5f0521a7327bd3"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"2f8d186b4821bfaa52279e5bc1c3fc30bda37561","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ed4fab0d_bcd7341e","in_reply_to":"03aa320e_8bcca776","updated":"2024-05-08 21:10:40.000000000","message":"So I have tried all possible combinations of commands with lr-nat-add (private subnet cidr 10.0.0.0/26) and I can\u0027t get both floating IP and default SNAT to work at the same time. For example these three addresses for logical_ip field:\n\n0.0.0.0/0\n10.0.0.0/26\n0.0.0.0 (implicit /32)\n255.255.255.255\netc\n\nSo at this point I\u0027m guessing there is something in OVN at play here and we will need to either list all the cidrs, or all the IPs on the subnets. The former is easier.","commit_id":"0630d1b60b3091ddd0fc7afd9e5f0521a7327bd3"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"2303990e03322f9e88199fd1b84697c35cb526e5","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"1f5e032e_5107df70","in_reply_to":"ed4fab0d_bcd7341e","updated":"2024-05-15 21:36:52.000000000","message":"Thanks for pursuing this.","commit_id":"0630d1b60b3091ddd0fc7afd9e5f0521a7327bd3"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"f7c1de6f0a8631bba6692265e65b577e17ab3fa1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"03aa320e_8bcca776","in_reply_to":"f34358cb_8020a0c4","updated":"2024-05-06 23:43:01.000000000","message":"Looking at conntrack (sudo ovs-appctl dpctl/dump-conntrack | grep 172.24.4.217) the entries look correct and similar to no patch.\n\nicmp,orig\u003d(src\u003d10.0.0.13,dst\u003d172.24.4.17,id\u003d39404,type\u003d8,code\u003d0),reply\u003d(src\u003d172.24.4.17,dst\u003d172.24.4.217,id\u003d39404,type\u003d0,code\u003d0),zone\u003d4\nicmp,orig\u003d(src\u003d172.24.4.217,dst\u003d172.24.4.17,id\u003d39404,type\u003d8,code\u003d0),reply\u003d(src\u003d10.0.0.56,dst\u003d172.24.4.217,id\u003d39404,type\u003d0,code\u003d0),zone\u003d7\nicmp,orig\u003d(src\u003d10.0.0.13,dst\u003d172.24.4.17,id\u003d39404,type\u003d8,code\u003d0),reply\u003d(src\u003d172.24.4.17,dst\u003d10.0.0.13,id\u003d39404,type\u003d0,code\u003d0),zone\u003d9","commit_id":"0630d1b60b3091ddd0fc7afd9e5f0521a7327bd3"}]}