)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"89395b384fd6a172635471063396f25dbbc13836","unresolved":true,"context_lines":[{"line_number":12,"context_line":"(and therefore always appears in desired_network_ids), but it is"},{"line_number":13,"context_line":"never added to net_vnic_type_map because it is not a member network."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"When the VIP network has not yet been plugged into the amphora it"},{"line_number":16,"context_line":"appears in add_ids, and the list comprehension that builds add_nics"},{"line_number":17,"context_line":"performs a bare dict lookup net_vnic_type_map[add_net_id].  This can"},{"line_number":18,"context_line":"result in an unhandled KeyError when a load balancer has no SR-IOV"},{"line_number":19,"context_line":"members (e.g. no members at all, or during initial amphora boot)."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Replace the bare lookup with dict.get() using VNIC_TYPE_NORMAL as the"},{"line_number":22,"context_line":"default.  VIP ports are always normal (non-SR-IOV), so this is"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"ea7af270_ec025839","line":19,"range":{"start_line":15,"start_character":0,"end_line":19,"end_character":65},"updated":"2026-05-13 08:05:31.000000000","message":"it\u0027s a bit messy here, the commit message is not accurate.\n\nIf the VIP network is also the management network, the network is not added to the network_to_nic_map dict, and that triggers the problem.\n\nThe patch appears to fix the KeyError exception but it also appears to have weird side effects:\n\nafter create a LB on lb-mgmt-net, adding a member on another subnet, then deleting the member, octavia keeps creating new interfaces on the managemnet network:\n\n```\nbash-5.2# ip -n amphora-haproxy a\n1: lo: \u003cLOOPBACK,UP,LOWER_UP\u003e mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000\n    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1/8 scope host lo\n       valid_lft forever preferred_lft forever\n3: eth1: \u003cBROADCAST,MULTICAST,UP,LOWER_UP\u003e mtu 1442 qdisc fq_codel state UP group default qlen 1000\n    link/ether fa:16:3e:1e:4c:c8 brd ff:ff:ff:ff:ff:ff\n    altname enp0s7\n    altname enxfa163e1e4cc8\n    inet 192.168.0.117/24 scope global eth1\n       valid_lft forever preferred_lft forever\n    inet 192.168.0.183/32 scope global eth1\n       valid_lft forever preferred_lft forever\n4: eth2: \u003cBROADCAST,MULTICAST,UP,LOWER_UP\u003e mtu 1442 qdisc fq_codel state UP group default qlen 1000\n    link/ether fa:16:3e:fe:ef:18 brd ff:ff:ff:ff:ff:ff\n    altname enp0s8\n    altname enxfa163efeef18\n    inet 192.168.0.3/24 scope global eth2\n       valid_lft forever preferred_lft forever\n    inet6 fe80::f816:3eff:fefe:ef18/64 scope link proto kernel_ll \n       valid_lft forever preferred_lft forever\n6: eth3: \u003cBROADCAST,MULTICAST,UP,LOWER_UP\u003e mtu 1442 qdisc fq_codel state UP group default qlen 1000\n    link/ether fa:16:3e:73:1f:ed brd ff:ff:ff:ff:ff:ff\n    altname enp0s10\n    altname enxfa163e731fed\n    inet 192.168.0.2/24 scope global eth3\n       valid_lft forever preferred_lft forever\n    inet6 fe80::f816:3eff:fe73:1fed/64 scope link proto kernel_ll \n       valid_lft forever preferred_lft forever\n```\n\nIn my devstack env with only 1 LB in Active-Standby, 7 IP addresses are consumed:\n\n```\n$ openstack port list --fixed-ip subnet\u003dlb-mgmt-subnet\n+--------------------------------------+--------------------------------------------------------+-------------------+------------------------------------------------------------------------------+--------+\n| ID                                   | Name                                                   | MAC Address       | Fixed IP Addresses                                                           | Status |\n+--------------------------------------+--------------------------------------------------------+-------------------+------------------------------------------------------------------------------+--------+\n| 096556d4-e1d3-4909-9664-3d683e68ce5a | octavia-health-manager-standalone-listen-port          | fa:16:3e:4a:8e:1b | ip_address\u003d\u0027192.168.0.93\u0027, subnet_id\u003d\u00278e3af031-2c45-494a-b9de-e1c040ef0975\u0027  | ACTIVE |\n| 22a3714e-e570-4b80-b53f-b7bda7e79bfa | octavia-lb-member-73c4130e-b1eb-4a9c-8c6a-f5d28f365bd9 | fa:16:3e:42:03:05 | ip_address\u003d\u0027192.168.0.148\u0027, subnet_id\u003d\u00278e3af031-2c45-494a-b9de-e1c040ef0975\u0027 | ACTIVE |\n| 5608f02f-6a85-4fe5-8a64-99be4c807c4a | octavia-lb-vrrp-73c4130e-b1eb-4a9c-8c6a-f5d28f365bd9   | fa:16:3e:aa:8f:43 | ip_address\u003d\u0027192.168.0.51\u0027, subnet_id\u003d\u00278e3af031-2c45-494a-b9de-e1c040ef0975\u0027  | ACTIVE |\n| 6a6a7f41-b7a8-4a4d-ac5b-8217ade81de7 | octavia-lb-member-29f4617c-6ad8-45a3-85e4-aba748f54f5d | fa:16:3e:73:1f:ed | ip_address\u003d\u0027192.168.0.2\u0027, subnet_id\u003d\u00278e3af031-2c45-494a-b9de-e1c040ef0975\u0027   | ACTIVE |\n| 70b92279-e890-44c5-8533-8f947f81fd9f |                                                        | fa:16:3e:a7:55:46 | ip_address\u003d\u0027192.168.0.105\u0027, subnet_id\u003d\u00278e3af031-2c45-494a-b9de-e1c040ef0975\u0027 | ACTIVE |\n| 735f52a3-458d-4d87-ad99-ea4144a2737a | octavia-lb-member-29f4617c-6ad8-45a3-85e4-aba748f54f5d | fa:16:3e:fe:ef:18 | ip_address\u003d\u0027192.168.0.3\u0027, subnet_id\u003d\u00278e3af031-2c45-494a-b9de-e1c040ef0975\u0027   | ACTIVE |\n| 77ad6005-4a9a-46c5-a0d3-039751dba322 |                                                        | fa:16:3e:52:70:0c | ip_address\u003d\u0027192.168.0.130\u0027, subnet_id\u003d\u00278e3af031-2c45-494a-b9de-e1c040ef0975\u0027 | ACTIVE |\n| 7dd8a8d7-ebea-4885-a81b-097aebf4c586 | octavia-lb-25ce2873-0364-4f90-8820-87aa1bbd3148        | fa:16:3e:6b:74:d7 | ip_address\u003d\u0027192.168.0.183\u0027, subnet_id\u003d\u00278e3af031-2c45-494a-b9de-e1c040ef0975\u0027 | DOWN   |\n| 9ae5a6e0-c484-4be5-8295-ea58950d4edd | octavia-lb-vrrp-29f4617c-6ad8-45a3-85e4-aba748f54f5d   | fa:16:3e:1e:4c:c8 | ip_address\u003d\u0027192.168.0.117\u0027, subnet_id\u003d\u00278e3af031-2c45-494a-b9de-e1c040ef0975\u0027 | ACTIVE |\n| f353607b-6780-4468-9663-a401cb750c83 | octavia-lb-member-73c4130e-b1eb-4a9c-8c6a-f5d28f365bd9 | fa:16:3e:82:81:b2 | ip_address\u003d\u0027192.168.0.173\u0027, subnet_id\u003d\u00278e3af031-2c45-494a-b9de-e1c040ef0975\u0027 | ACTIVE |\n+--------------------------------------+--------------------------------------------------------+-------------------+------------------------------------------------------------------------------+--------+\n```\n\nIMHO the patch doesn\u0027t take the right approach, it needs a special handling for the management network.","commit_id":"334ca2bfc73ed94fd16533c84056d0de45e4fcf4"}]}