)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":34451,"name":"Fernando Royo","email":"froyo@redhat.com","username":"froyo"},"change_message_id":"f2c7ee37fa3236f3df58a7dbde6e49603b09bb6c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"f3fe1a3f_a433b179","updated":"2026-05-19 13:20:55.000000000","message":"@luca.delmonte5@gmail.com what about this fix taking into account that other already merged? https://review.opendev.org/c/openstack/ovn-octavia-provider/+/980407","commit_id":"5d733cb9a9caf3dc296d208f407806f15cc40e6f"},{"author":{"_account_id":37774,"name":"Luca Del Monte","display_name":"Luca Del Monte","email":"luca.delmonte5@gmail.com","username":"lucadelmonte"},"change_message_id":"a6a4665b0c3b7f9c1f9aff788f97694e4e038301","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"f09ed332_818ed69c","in_reply_to":"f3fe1a3f_a433b179","updated":"2026-05-19 16:56:47.000000000","message":"Thanks for the pointer Fernando. Heads-up: I\u0027m no longer working with the ovn-octavia-provider, so I won\u0027t be following up on this patch myself. But here\u0027s what I found comparing the two — feel free to pick it up or hand it off.\n\nThe two patches address different bugs:\n\n#980407 (bug 2052843) fixes the VIP subnet connected to multiple routers case. It renames _find_lr_of_ls → _find_lrs_of_ls, _get_related_lr → _get_related_lrs, updates the sync/member-create call sites to iterate over all LRs, and teaches _del_lb_to_lr_association to preserve networks that are still reachable via remaining routers. It deliberately allows lr_ref to contain multiple routers (\"r1,r2\").\n\nThis patch (bug 1966052) fixes lb_create_lrp_assoc — the LRP_CREATE event handler. On an LRP create, the loop over network_lb - router_lb was indiscriminately attaching every LB on info[\u0027network\u0027] to info[\u0027router\u0027], even when info[\u0027network\u0027] is only a member network of the LB and the LB belongs to a different router. 980407 did not modify lb_create_lrp_assoc, and I verified on current master (post-980407) that the LP 1966052 reproducer still hits.\n\nOne thing to fix before landing: the check at helper.py:339-344 (if lr_ref and info[\u0027router\u0027].name not in lr_ref: continue) is correct for the member-network case but conflicts with 980407\u0027s intent when a new router later attaches to an LB\u0027s VIP subnet — in that scenario 980407 wants lr_ref to grow from \"r1\" to \"r1,r2\", but my check would skip it. The fix is to differentiate VIP network vs member network: allow association when info[\u0027network\u0027] is the LB\u0027s VIP network (lookup via LB_EXT_IDS_VIP_PORT_ID_KEY or matching vip_network_id), and only require \"router already in lr_ref\" for member networks. Worth adding a multi-router-VIP test case to lock that behavior in.\n\nThe ls_refs check (lines 311-332) and the second loop\u0027s check (lines 365-370) should stay as-is — they\u0027re independent of the 980407 interaction.\n\nHappy to answer questions if anyone picks this up, but I won\u0027t be pushing new patchsets. Feel free to abandon and re-submit under a new owner, or take it over directly.","commit_id":"5d733cb9a9caf3dc296d208f407806f15cc40e6f"}],"ovn_octavia_provider/helper.py":[{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"e3329099b20e5ecdbdcdcf9e979e98af8ce59027","unresolved":true,"context_lines":[{"line_number":319,"context_line":"                try:"},{"line_number":320,"context_line":"                    ls_refs_dict \u003d jsonutils.loads(ls_refs)"},{"line_number":321,"context_line":"                except ValueError:"},{"line_number":322,"context_line":"                    ls_refs_dict \u003d {}"},{"line_number":323,"context_line":"                # Only associate if this network is tracked in the LB\u0027s ls_refs"},{"line_number":324,"context_line":"                if info[\u0027network\u0027].name not in ls_refs_dict:"},{"line_number":325,"context_line":"                    LOG.debug(\"Skipping association of LB %s to router %s: \""}],"source_content_type":"text/x-python","patch_set":3,"id":"a8ebb353_1ed187ce","line":322,"updated":"2026-03-10 11:00:08.000000000","message":"why not simply \"continue\" here?","commit_id":"8eddff41a2c6ba2abcb2a30802ed863ebd63d633"},{"author":{"_account_id":37774,"name":"Luca Del Monte","display_name":"Luca Del Monte","email":"luca.delmonte5@gmail.com","username":"lucadelmonte"},"change_message_id":"a6a4665b0c3b7f9c1f9aff788f97694e4e038301","unresolved":false,"context_lines":[{"line_number":319,"context_line":"                try:"},{"line_number":320,"context_line":"                    ls_refs_dict \u003d jsonutils.loads(ls_refs)"},{"line_number":321,"context_line":"                except ValueError:"},{"line_number":322,"context_line":"                    ls_refs_dict \u003d {}"},{"line_number":323,"context_line":"                # Only associate if this network is tracked in the LB\u0027s ls_refs"},{"line_number":324,"context_line":"                if info[\u0027network\u0027].name not in ls_refs_dict:"},{"line_number":325,"context_line":"                    LOG.debug(\"Skipping association of LB %s to router %s: \""}],"source_content_type":"text/x-python","patch_set":3,"id":"dcd1afc8_948c0e24","line":322,"in_reply_to":"a8ebb353_1ed187ce","updated":"2026-05-19 16:56:47.000000000","message":"Good point, simplified to continue directly. Added a LOG.debug before the continue to keep the skipping reason visible.","commit_id":"8eddff41a2c6ba2abcb2a30802ed863ebd63d633"}]}