)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":35873,"name":"Daniel Failing","display_name":"Daniel Failing","email":"dev@danfai.de","username":"danfai"},"change_message_id":"38fd9af6894f8c790f468018fb97b024ec9bbc0c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"de612408_e103f7b5","updated":"2024-07-11 14:36:01.000000000","message":"From my point of view every amphora configured for an Active-Active LB is supposed to be an BGP speaker as well. Not sure if this is what you are also trying to convene.","commit_id":"fca378a7c24636bf382c7b7085f29ad5d51e705e"},{"author":{"_account_id":35873,"name":"Daniel Failing","display_name":"Daniel Failing","email":"dev@danfai.de","username":"danfai"},"change_message_id":"e3bea135ff9223236279a6b0b5b628439cbb4ac1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"9077b0f2_ccc1beda","updated":"2026-06-05 09:49:00.000000000","message":"A general issue I haven\u0027t had a solution for was what to do with healthchecks for the backends. Imagine a situation where there is a network partition and one of the amphora can reach the backends, while another one doesn\u0027t have access to any backends anymore. Now it would be nice to drop the BGP announcements and have the other amphora deal with all the traffic, as it has working members. However, if there is a real issue on the backends, it would be nice to the users to get the 503 (or similar) to see that the backend service is actually down.\nI think, this problem is a more generic problem for all A/A solutions and as far as I can see there is no easy non-complex solution, but happy to hear otherwise.\nLeaving this comment here to have it mentioned, and I think the current approach should at least be the first version and this comment can be addressed in a future spec or improvement","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":39115,"name":"Vinicius Marques Rodrigues","email":"vinicius.marques.rodrigues@cern.ch","username":"viniciusr"},"change_message_id":"789df541151ae448ce5f821052a5f4e85bde82b0","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":6,"id":"3b419d60_d3c60b09","updated":"2026-06-19 08:53:34.000000000","message":"As discussed in the last weekly octavia meeting, here\u0027s is a summary of\nour current A/A BGP setup at CERN (and a bit of the environment):\n\nEnvironment:\n* We have two regions.\n* In both regions there is a single public flat network.\n  It\u0027s a routed network, leveraging the segment functionality of Neutron.\n\nOctavia:\n* LB Management network: it differs in each region. In one uses an interface \n  in the public network, while the other relies on a private network to the\n  controllers.\n* We have some downstream patches on top of octavia to fit in our segmented network,\n  and ensure it picks the right subnets and hosts.\n* We enforce dual-stack everywhere, including downstream patches.\n\nActiveActive Lab:\n* We have two upstream BPG peers in the setup. They\u0027re two routers configured\n  to accept /32,/128 announcements in a specific subnet (vip_subnet) from\n  a specific subnet (vrrp_subnet / frontend_subnet).\n* We make use of the ebgp-multihop feature.\n* Given that LB management in our environment can be a private network not routed,\n  we prefer to have FRR running on the amphora-haproxy namespace, and have the\n  option of re-using the frontend_subnet for the announcements.\n* In our environment, we plan to expose a set of \"active-active\" flavors (in different sizes)\n  for the end-users to consume. All the distributor, peers, etc, is exclusively\n  managed by the admins","commit_id":"7f5290ab960e71926f451f72128757d888acfa5c"},{"author":{"_account_id":38924,"name":"YushoYamaguchi","display_name":"YushoYamaguchi","email":"ys-yamaguchi@kddi.com","username":"YushoYamaguchi"},"change_message_id":"f1ca216df599fab21664366ed98f7b295a02fe04","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"f2a4ae66_e68c5578","updated":"2026-07-09 02:17:05.000000000","message":"From an operational perspective, it would be great to have support for:\n\n- Multi-hop eBGP\n- The ability to stop advertising a VIP when all pool members are down (for IP Anycast deployments where the same VIP is advertised from multiple locations)","commit_id":"7f5290ab960e71926f451f72128757d888acfa5c"},{"author":{"_account_id":38924,"name":"YushoYamaguchi","display_name":"YushoYamaguchi","email":"ys-yamaguchi@kddi.com","username":"YushoYamaguchi"},"change_message_id":"c6a389e3bdc6552ad1b93c940ed6b5462a4c50f6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"f6fc6425_b628442e","updated":"2026-07-09 01:50:11.000000000","message":"From an operational scalability perspective, it would be beneficial to support establishing BGP sessions without explicitly specifying remote-as,\nby leveraging FRR\u0027s remote-as internal, remote-as external, or remote-as auto capabilities.\nhttps://docs.frrouting.org/en/latest/bgp.html#clicmd-neighbor-PEER-remote-as-internal","commit_id":"7f5290ab960e71926f451f72128757d888acfa5c"},{"author":{"_account_id":35873,"name":"Daniel Failing","display_name":"Daniel Failing","email":"dev@danfai.de","username":"danfai"},"change_message_id":"13099bff6be063cde59109bf6505a6404da2fe47","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"b01fbb6d_a8ce4975","in_reply_to":"f2a4ae66_e68c5578","updated":"2026-07-16 18:49:24.000000000","message":"For the VIP advertisement for anycast, I also added the comment before here: https://review.opendev.org/c/openstack/octavia/+/888020/comments/9077b0f2_ccc1beda\n\nI think one solution might actually be to have the frr announce the route with a lower preference/higher cost, such that the distributor/RR/routers can choose the one with a higher preference/lower cost. This way even if all amphora\u0027s have no backends, the IP would stay available and haproxy can return the 503.","commit_id":"7f5290ab960e71926f451f72128757d888acfa5c"}],"doc/source/contributor/index.rst":[{"author":{"_account_id":34429,"name":"Tom Weininger","email":"dienste@weinimo.de","username":"tweining"},"change_message_id":"4181fb70d358c49672b37c34b5d5a7e68781af5f","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"   specs/version1.1/*"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Version 1.2 (bobcat)"},{"line_number":94,"context_line":"````````````````````"},{"line_number":95,"context_line":".. toctree::"},{"line_number":96,"context_line":"   :glob:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7dc6b846_b9d7a329","line":93,"range":{"start_line":93,"start_character":0,"end_line":93,"end_character":20},"updated":"2023-10-24 11:38:48.000000000","message":"Needs an update.","commit_id":"796199ff17f92797d8e444709628599b35eb8084"}],"specs/version1.2/active-active-l3-distributor.rst":[{"author":{"_account_id":34429,"name":"Tom Weininger","email":"dienste@weinimo.de","username":"tweining"},"change_message_id":"4181fb70d358c49672b37c34b5d5a7e68781af5f","unresolved":true,"context_lines":[{"line_number":52,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"* Octavia shall implement the *L3 active-active* distributor as an alternative"},{"line_number":55,"context_line":"  driver which could replace VRRP in the Amphora driver."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"* The distributor control plane function (*bgp speaker*) will run inside the"},{"line_number":58,"context_line":"  amphora and leverage the existing amphora lifecycle manager."}],"source_content_type":"text/x-rst","patch_set":1,"id":"0916c0a8_891b2d8b","line":55,"range":{"start_line":55,"start_character":15,"end_line":55,"end_character":56},"updated":"2023-10-24 11:38:48.000000000","message":"Just to avoid misunderstanding and to be clear. That new driver will not replace the VRRP driver used for active-standby topology, right?","commit_id":"796199ff17f92797d8e444709628599b35eb8084"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"d5bee582a4cbd5e6b26fb19fd9d9badc0d59403c","unresolved":true,"context_lines":[{"line_number":52,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"* Octavia shall implement the *L3 active-active* distributor as an alternative"},{"line_number":55,"context_line":"  driver which could replace VRRP in the Amphora driver."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"* The distributor control plane function (*bgp speaker*) will run inside the"},{"line_number":58,"context_line":"  amphora and leverage the existing amphora lifecycle manager."}],"source_content_type":"text/x-rst","patch_set":1,"id":"cf6e1a2b_8357fe81","line":55,"range":{"start_line":55,"start_character":15,"end_line":55,"end_character":56},"in_reply_to":"0916c0a8_891b2d8b","updated":"2023-10-24 11:54:06.000000000","message":"nop, but it could 😄\n\nVRRP driver will still be available. The BGP driver provides a few improvements (like active-active instead of active-standby), but it also requires additional services in the cloud or in the infra (BGP support).\n\nwhat about:\n| an alternative driver which could be used instead of the VRRP driver in the Amphora driver","commit_id":"796199ff17f92797d8e444709628599b35eb8084"},{"author":{"_account_id":34429,"name":"Tom Weininger","email":"dienste@weinimo.de","username":"tweining"},"change_message_id":"9c5625de0b7f9b9e021bd9b704d47f3cb04f301b","unresolved":true,"context_lines":[{"line_number":52,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"* Octavia shall implement the *L3 active-active* distributor as an alternative"},{"line_number":55,"context_line":"  driver which could replace VRRP in the Amphora driver."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"* The distributor control plane function (*bgp speaker*) will run inside the"},{"line_number":58,"context_line":"  amphora and leverage the existing amphora lifecycle manager."}],"source_content_type":"text/x-rst","patch_set":1,"id":"4c77b2cb_535d4f56","line":55,"range":{"start_line":55,"start_character":15,"end_line":55,"end_character":56},"in_reply_to":"cf6e1a2b_8357fe81","updated":"2023-10-24 12:06:25.000000000","message":"Sounds good to me. Thanks.","commit_id":"796199ff17f92797d8e444709628599b35eb8084"},{"author":{"_account_id":35873,"name":"Daniel Failing","display_name":"Daniel Failing","email":"dev@danfai.de","username":"danfai"},"change_message_id":"38fd9af6894f8c790f468018fb97b024ec9bbc0c","unresolved":true,"context_lines":[{"line_number":167,"context_line":"  │             │                                               ║"},{"line_number":168,"context_line":"  │             ╞═══════════════════════════════════════════════Anycast"},{"line_number":169,"context_line":"  └─────────────┘                     1..*                      Network"},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"* Whenever a new active-active amphora is instantiated it will create BGP"},{"line_number":172,"context_line":"  peering session(s) over the distributor network to the L3 fabric. The BGP"},{"line_number":173,"context_line":"  peer will need to have a neighbor definition in order to allow the peering"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b48bb872_8d4e705d","line":170,"updated":"2024-07-11 14:36:01.000000000","message":"Would it make more sense to put the BGP speaker in the amphora-haproxy namespace?\nThe benefit would be, that the mgmt network can be a private network only shared with the octavia controller workers and nothing else. The BGP session however needs to be established with the network.\nAnother idea would be to add another network namespace for this. The drawback however is, that you need another distributor IP, which can be saved in case you use the external network.","commit_id":"fca378a7c24636bf382c7b7085f29ad5d51e705e"},{"author":{"_account_id":35873,"name":"Daniel Failing","display_name":"Daniel Failing","email":"dev@danfai.de","username":"danfai"},"change_message_id":"92f290dc7456e15367905a56e123093ccf13b4f4","unresolved":true,"context_lines":[{"line_number":167,"context_line":"  │             │                                               ║"},{"line_number":168,"context_line":"  │             ╞═══════════════════════════════════════════════Anycast"},{"line_number":169,"context_line":"  └─────────────┘                     1..*                      Network"},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"* Whenever a new active-active amphora is instantiated it will create BGP"},{"line_number":172,"context_line":"  peering session(s) over the distributor network to the L3 fabric. The BGP"},{"line_number":173,"context_line":"  peer will need to have a neighbor definition in order to allow the peering"}],"source_content_type":"text/x-rst","patch_set":2,"id":"f1913702_e4a87645","line":170,"in_reply_to":"1281c0a4_4b9c62f4","updated":"2026-05-11 09:49:21.000000000","message":"One option with private networks would be to put all BGP related communication inside a private network (and inside a dedicated namespace in the amphora for that). Then you only have maybe 2 or so route-reflector communicating externally via BGP. This might reduce the number of BGP sessions on the ToR/Router significantly and allows for easier maintenance between teams, when responsibilities between the teams are separated (you only have to change the route-reflector rather than all amphoras).\nHowever, this should also be feasible inside the amphora-haproxy namespace, when using public networks. \n(and Amphoras inside a private network for BGP would anyway not make sense from what I wonder. Then you would deal with floating IPs or similar already, and the BGP part would move there instead.)","commit_id":"fca378a7c24636bf382c7b7085f29ad5d51e705e"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"a2de0241c4ad3df177b6fdca5fae7326745db0af","unresolved":true,"context_lines":[{"line_number":167,"context_line":"  │             │                                               ║"},{"line_number":168,"context_line":"  │             ╞═══════════════════════════════════════════════Anycast"},{"line_number":169,"context_line":"  └─────────────┘                     1..*                      Network"},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"* Whenever a new active-active amphora is instantiated it will create BGP"},{"line_number":172,"context_line":"  peering session(s) over the distributor network to the L3 fabric. The BGP"},{"line_number":173,"context_line":"  peer will need to have a neighbor definition in order to allow the peering"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d8ddc87b_93246648","line":170,"in_reply_to":"b48bb872_8d4e705d","updated":"2025-01-14 14:13:13.000000000","message":"I need to read again my implementation, but I got the same question","commit_id":"fca378a7c24636bf382c7b7085f29ad5d51e705e"},{"author":{"_account_id":39115,"name":"Vinicius Marques Rodrigues","email":"vinicius.marques.rodrigues@cern.ch","username":"viniciusr"},"change_message_id":"a5972ea7f458944d40308bb50a53db3b08825eb2","unresolved":true,"context_lines":[{"line_number":167,"context_line":"  │             │                                               ║"},{"line_number":168,"context_line":"  │             ╞═══════════════════════════════════════════════Anycast"},{"line_number":169,"context_line":"  └─────────────┘                     1..*                      Network"},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"* Whenever a new active-active amphora is instantiated it will create BGP"},{"line_number":172,"context_line":"  peering session(s) over the distributor network to the L3 fabric. The BGP"},{"line_number":173,"context_line":"  peer will need to have a neighbor definition in order to allow the peering"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1281c0a4_4b9c62f4","line":170,"in_reply_to":"d8ddc87b_93246648","updated":"2026-05-07 13:24:44.000000000","message":"Following up on this since we\u0027ve now deployed BGP-AA (using the bgp-exp topic, which already establishes BGP through the amphora-haproxy namespace) and can confirm the behavior.\nThe implementation puts FRR in the amphora-haproxy namespace, which is what Daniel was suggesting. The lb-mgmt-net stays fully private as Daniel hoped, no extra namespace or distributor IP is needed. BGP peers from the existing front-end address (amphora.vrrp_ip), and outbound route-maps explicitly set the advertised next-hop to that same address — so the fabric forwards VIP traffic directly to eth1 in the amphora-haproxy namespace, regardless of how the BGP session itself is routed.\nGiven the code already does the right thing, I think the spec text just needs to be updated to match. Happy to send a patch if that\u0027s useful. Open to any further considerations or alternative perspectives on this.","commit_id":"fca378a7c24636bf382c7b7085f29ad5d51e705e"},{"author":{"_account_id":35873,"name":"Daniel Failing","display_name":"Daniel Failing","email":"dev@danfai.de","username":"danfai"},"change_message_id":"38fd9af6894f8c790f468018fb97b024ec9bbc0c","unresolved":true,"context_lines":[{"line_number":636,"context_line":"    ``distributor_id`` is required and must only be used with MULTI_ACTIVE"},{"line_number":637,"context_line":"    topology."},{"line_number":638,"context_line":""},{"line_number":639,"context_line":"    ``distributor_id`` cannot be updated after the creation of a load balancer."},{"line_number":640,"context_line":""},{"line_number":641,"context_line":"    [`P2`_] Support for multiple distributors per load balancer."},{"line_number":642,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1804e22c_23ac58d1","line":639,"updated":"2024-07-11 14:36:01.000000000","message":"Would it be worth considering putting the distributor ID in a flavor?\nThe current API allows to specify the loadbalancer_topology in a flavorprofile, so it would make sense to add this information to the flavorprofile.\nWhat I dislike about this is, that there would be a mix of information in the database as separate table and other information in the JSON blob of the flavorprofile. The big benefit is, that a) there is no API change, b) the distributor IP can be configured by the operators and the user only has to select a different flavor.\n\nThis would break in case a tenant network should be used for the distributor network if users have their own BGP peers. This scenario seems unlikely though.","commit_id":"fca378a7c24636bf382c7b7085f29ad5d51e705e"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"a2de0241c4ad3df177b6fdca5fae7326745db0af","unresolved":true,"context_lines":[{"line_number":636,"context_line":"    ``distributor_id`` is required and must only be used with MULTI_ACTIVE"},{"line_number":637,"context_line":"    topology."},{"line_number":638,"context_line":""},{"line_number":639,"context_line":"    ``distributor_id`` cannot be updated after the creation of a load balancer."},{"line_number":640,"context_line":""},{"line_number":641,"context_line":"    [`P2`_] Support for multiple distributors per load balancer."},{"line_number":642,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"2020c00b_437b2cf5","line":639,"in_reply_to":"1804e22c_23ac58d1","updated":"2025-01-14 14:13:13.000000000","message":"I\u0027m surprised that I didn\u0027t think about it, but yeah it\u0027s a great idea.","commit_id":"fca378a7c24636bf382c7b7085f29ad5d51e705e"}],"specs/version15.0/active-active-l3-distributor.rst":[{"author":{"_account_id":38562,"name":"Richard Cruise","email":"rcruise@redhat.com","username":"rcruise"},"tag":"autogenerated:claude-review","change_message_id":"1584465d5ad7c960856d07f3fdbee33d58f63928","unresolved":false,"context_lines":[{"line_number":85,"context_line":"* A load balancer supports a single *bgp speaker* configuration (with multiple"},{"line_number":86,"context_line":"  BGP peers)."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"* [`P2_`] A load balancer will handle multiple *bgp speaker* configuration."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"* [`P2`_] Add the option to allow the *bgp speaker* to run on a dedicated"},{"line_number":91,"context_line":"  amphora instance that is not running the software load balancer (HAProxy). In"}],"source_content_type":"text/x-rst","patch_set":4,"id":"57815b21_b970fb02","line":88,"updated":"2026-06-04 08:22:30.000000000","message":"Broken RST cross-reference. Uses `` [`P2_`] `` instead of the\n  correct `` [`P2`_] `` form. The underscore must be outside the backtick to\n  be interpreted as a hyperlink reference in Sphinx.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"3aeee2c7d5070bb4064d131a25f9e831214d7b5a","unresolved":true,"context_lines":[{"line_number":297,"context_line":"* ``description`` (String(255), nullable\u003dTrue)"},{"line_number":298,"context_line":"    Description of Distributor instance."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"* ``project_id`` (String(36), nullable\u003dFalse)"},{"line_number":301,"context_line":"    Project of the Distributor instance."},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"* ``enabled`` (bool, nullable\u003dFalse)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1c8e896f_60543204","line":300,"range":{"start_line":300,"start_character":4,"end_line":300,"end_character":14},"updated":"2026-06-04 16:13:07.000000000","message":"Do we need per project distributors? or global distributors?","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"4d6ad222cf8e4ab60ead4a0a9f9c36df164fec0d","unresolved":true,"context_lines":[{"line_number":297,"context_line":"* ``description`` (String(255), nullable\u003dTrue)"},{"line_number":298,"context_line":"    Description of Distributor instance."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"* ``project_id`` (String(36), nullable\u003dFalse)"},{"line_number":301,"context_line":"    Project of the Distributor instance."},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"* ``enabled`` (bool, nullable\u003dFalse)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6594a3f6_fb7e9a89","line":300,"range":{"start_line":300,"start_character":4,"end_line":300,"end_character":14},"in_reply_to":"161ff951_6d11b697","updated":"2026-06-05 06:09:49.000000000","message":"I agree, and as we want to include distributor_id in flavors, they have to be global objects","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"755eb3dfe29087f6a35e21a8bfd5f2ed8ce83b32","unresolved":true,"context_lines":[{"line_number":297,"context_line":"* ``description`` (String(255), nullable\u003dTrue)"},{"line_number":298,"context_line":"    Description of Distributor instance."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"* ``project_id`` (String(36), nullable\u003dFalse)"},{"line_number":301,"context_line":"    Project of the Distributor instance."},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"* ``enabled`` (bool, nullable\u003dFalse)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"161ff951_6d11b697","line":300,"range":{"start_line":300,"start_character":4,"end_line":300,"end_character":14},"in_reply_to":"1c8e896f_60543204","updated":"2026-06-04 19:51:58.000000000","message":"I think global distributors managed by the administrators look more appropriate.\n\nEven if global, we could consider making them public/private, and potentially have the ability of sharing private ones with some projects. This is not a scenario we\u0027ll find in our environment I think, but maybe others could have the situation of providing different \"tiers\" of distributors configuration, or even no distributors at all for some projects.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":35873,"name":"Daniel Failing","display_name":"Daniel Failing","email":"dev@danfai.de","username":"danfai"},"change_message_id":"13099bff6be063cde59109bf6505a6404da2fe47","unresolved":true,"context_lines":[{"line_number":297,"context_line":"* ``description`` (String(255), nullable\u003dTrue)"},{"line_number":298,"context_line":"    Description of Distributor instance."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"* ``project_id`` (String(36), nullable\u003dFalse)"},{"line_number":301,"context_line":"    Project of the Distributor instance."},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"* ``enabled`` (bool, nullable\u003dFalse)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9779b222_9cafddf1","line":300,"range":{"start_line":300,"start_character":4,"end_line":300,"end_character":14},"in_reply_to":"2acdd2e4_9b3eb1a5","updated":"2026-07-16 18:49:24.000000000","message":"For having 2 different DCs, or different zones where some customers should have access to some distributors vs others, I would rather suggest to add per project flavor/flavorquota. That way you limit flavors per project and the flavors are the admin configured objects having the distributor ID. A (start of a) spec for per project flavor quota is also already here: https://review.opendev.org/c/openstack/octavia/+/948193","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":38562,"name":"Richard Cruise","email":"rcruise@redhat.com","username":"rcruise"},"change_message_id":"834d60e2779352f6bbe0746ed53be9aba1821741","unresolved":true,"context_lines":[{"line_number":297,"context_line":"* ``description`` (String(255), nullable\u003dTrue)"},{"line_number":298,"context_line":"    Description of Distributor instance."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"* ``project_id`` (String(36), nullable\u003dFalse)"},{"line_number":301,"context_line":"    Project of the Distributor instance."},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"* ``enabled`` (bool, nullable\u003dFalse)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"2acdd2e4_9b3eb1a5","line":300,"range":{"start_line":300,"start_character":4,"end_line":300,"end_character":14},"in_reply_to":"6594a3f6_fb7e9a89","updated":"2026-06-05 10:43:26.000000000","message":"I could actually see an argument for per project distributors. You could have 2 data centers in different regions with different data protection laws. Perhaps for legal reasons you also need to ensure that the admins in one region do not have access to the other. You could do this by having different projects per region, in which case you would want distributors per project to ensure your LBs aren\u0027t mixing traffic across projects","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"3d58bc6545e327791a43977ce576acc884bf94e8","unresolved":true,"context_lines":[{"line_number":306,"context_line":"* ``distributor_type`` (String(16), nullable\u003dFalse)"},{"line_number":307,"context_line":"    Type of distributor (foreign key to ``distributor_type.name``)."},{"line_number":308,"context_line":""},{"line_number":309,"context_line":"* ``provisioning_status`` (String(16), nullable\u003dFalse)"},{"line_number":310,"context_line":"    Provisioning status."},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Update existing table ``amphora``.  The vrrp_* tables may be renamed to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"2ebdfcf3_5deb92dd","line":309,"updated":"2026-06-05 14:20:55.000000000","message":"What sort of \"provisioning\"status\" do we foresee for the distributors? Would it be the right status representation? \n\nWould it make more sense to align it more with the \"operating_status\" ? I don\u0027t know if we could re-use the current status Octavia uses, or we move to something different.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"3194a10a7a842831aacd38195bcf60b1bbe2ed53","unresolved":true,"context_lines":[{"line_number":306,"context_line":"* ``distributor_type`` (String(16), nullable\u003dFalse)"},{"line_number":307,"context_line":"    Type of distributor (foreign key to ``distributor_type.name``)."},{"line_number":308,"context_line":""},{"line_number":309,"context_line":"* ``provisioning_status`` (String(16), nullable\u003dFalse)"},{"line_number":310,"context_line":"    Provisioning status."},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Update existing table ``amphora``.  The vrrp_* tables may be renamed to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5df11ebd_c827cbdd","line":309,"in_reply_to":"2ebdfcf3_5deb92dd","updated":"2026-06-18 13:40:00.000000000","message":"in case of BGP Peer/Speaker, it would always be ACTIVE, there\u0027s nothing to provision.\n\nit might be used if we extend the distributors to other types (like a distributor based on VMs spawned by Octavia)\n\nmaybe we should remove it from the spec, and add it later only if we need it.\n\noperating_status would be complex to implement with BGP as most of the components reside outside the Octavia control plane","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"16f902e90352310c95b0ccaef072129aa5e5b577","unresolved":true,"context_lines":[{"line_number":306,"context_line":"* ``distributor_type`` (String(16), nullable\u003dFalse)"},{"line_number":307,"context_line":"    Type of distributor (foreign key to ``distributor_type.name``)."},{"line_number":308,"context_line":""},{"line_number":309,"context_line":"* ``provisioning_status`` (String(16), nullable\u003dFalse)"},{"line_number":310,"context_line":"    Provisioning status."},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Update existing table ``amphora``.  The vrrp_* tables may be renamed to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"08598414_e75b8412","line":309,"in_reply_to":"5df11ebd_c827cbdd","updated":"2026-06-19 09:09:03.000000000","message":"Sounds good. No strong opinion on whether removing for now or keeping it as a forward looking aspect if we expect some other distributor type to appear.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":38562,"name":"Richard Cruise","email":"rcruise@redhat.com","username":"rcruise"},"tag":"autogenerated:claude-review","change_message_id":"1584465d5ad7c960856d07f3fdbee33d58f63928","unresolved":false,"context_lines":[{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Update existing table ``amphora``.  The vrrp_* tables may be renamed to"},{"line_number":313,"context_line":"frontend_* in order to make the purpose of this interface more apparent and to"},{"line_number":314,"context_line":"better represent other use cases besides active/standy."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"* ``distributor_port_id`` (String(36), nullable\u003dTrue)"},{"line_number":317,"context_line":"    Represents the Neutron port ID that is attached to the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5c4bdbfc_a34710fc","line":314,"updated":"2026-06-04 08:22:30.000000000","message":"Typo: \"active/standy\" → \"active/standby\".","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":38562,"name":"Richard Cruise","email":"rcruise@redhat.com","username":"rcruise"},"tag":"autogenerated:claude-review","change_message_id":"1584465d5ad7c960856d07f3fdbee33d58f63928","unresolved":false,"context_lines":[{"line_number":351,"context_line":"* ``auth_type`` (String(16), nullable\u003dTrue)"},{"line_number":352,"context_line":"    Authentication type (``md5`` or null)."},{"line_number":353,"context_line":""},{"line_number":354,"context_line":"* ``auth_pass`` (String(128), nullable\u003dTrue)"},{"line_number":355,"context_line":"    Authentication password (only if ``auth_type`` is not null)."},{"line_number":356,"context_line":""},{"line_number":357,"context_line":"* ``ttl_hops`` (Integer, nullable\u003dTrue)"},{"line_number":358,"context_line":"    Number of hops between speaker and peer for multi-hop BGP. When set,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ffc1a226_d1c6c068","line":355,"range":{"start_line":354,"start_character":0,"end_line":355,"end_character":0},"updated":"2026-06-04 08:22:30.000000000","message":"`auth_pass` is stored as a plaintext string. BGP MD5 passwords\n  are sensitive. The spec should address secret storage strategy.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":38562,"name":"Richard Cruise","email":"rcruise@redhat.com","username":"rcruise"},"tag":"autogenerated:claude-review","change_message_id":"1584465d5ad7c960856d07f3fdbee33d58f63928","unresolved":false,"context_lines":[{"line_number":369,"context_line":""},{"line_number":370,"context_line":"* ``id`` (String(36), nullable\u003dFalse, primary_key\u003dTrue)"},{"line_number":371,"context_line":"    ID of the BGP speaker. Each ``distributor_l3_bgp_speaker`` entry is"},{"line_number":372,"context_line":"    associated with a ``distributor`` entry of type ``BGP-PEER``, they share"},{"line_number":373,"context_line":"    the same ID."},{"line_number":374,"context_line":""},{"line_number":375,"context_line":"* ``name`` (String(255), nullable\u003dTrue)"},{"line_number":376,"context_line":"    Name of BGP speaker."}],"source_content_type":"text/x-rst","patch_set":4,"id":"4f31cd19_6c937b32","line":373,"range":{"start_line":372,"start_character":0,"end_line":373,"end_character":0},"updated":"2026-06-04 08:22:30.000000000","message":"Incorrect distributor type: *\"Each `distributor_l3_bgp_speaker`\n  entry is associated with a `distributor` entry of type `BGP-PEER`\"*. The\n  speaker table should be associated with type `BGP-SPEAKER`.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":38562,"name":"Richard Cruise","email":"rcruise@redhat.com","username":"rcruise"},"tag":"autogenerated:claude-review","change_message_id":"1584465d5ad7c960856d07f3fdbee33d58f63928","unresolved":false,"context_lines":[{"line_number":484,"context_line":"    Deleting a BGP Peer that is in use by a Load Balancer results in a"},{"line_number":485,"context_line":"    conflict error (409)."},{"line_number":486,"context_line":""},{"line_number":487,"context_line":"    Deleting a BGP Peer that is associated with a BGP speaker would delete both"},{"line_number":488,"context_line":"    objects."},{"line_number":489,"context_line":""},{"line_number":490,"context_line":"Distributor BGP Speaker API:"},{"line_number":491,"context_line":""},{"line_number":492,"context_line":"* **GET /v2.0/lbaas/distributors/bgp/speakers**"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6d1be4af_67485d60","line":489,"range":{"start_line":487,"start_character":0,"end_line":489,"end_character":0},"updated":"2026-06-04 08:22:30.000000000","message":"Cascading delete semantics (\"Deleting a BGP Peer that is\n  associated with a BGP speaker would delete both objects\") is unusual for\n  OpenStack APIs and could lead to inadvertent data loss.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"da9b67b3950670237a61e17f5346321c9a1860b2","unresolved":true,"context_lines":[{"line_number":484,"context_line":"    Deleting a BGP Peer that is in use by a Load Balancer results in a"},{"line_number":485,"context_line":"    conflict error (409)."},{"line_number":486,"context_line":""},{"line_number":487,"context_line":"    Deleting a BGP Peer that is associated with a BGP speaker would delete both"},{"line_number":488,"context_line":"    objects."},{"line_number":489,"context_line":""},{"line_number":490,"context_line":"Distributor BGP Speaker API:"},{"line_number":491,"context_line":""},{"line_number":492,"context_line":"* **GET /v2.0/lbaas/distributors/bgp/speakers**"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9bf93ad6_400df95e","line":489,"range":{"start_line":487,"start_character":0,"end_line":489,"end_character":0},"in_reply_to":"6d1be4af_67485d60","updated":"2026-06-05 06:30:10.000000000","message":"Makes sense, Deleting a BGP Peer assiocated with a BGP speaker could return a 409","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"3194a10a7a842831aacd38195bcf60b1bbe2ed53","unresolved":false,"context_lines":[{"line_number":484,"context_line":"    Deleting a BGP Peer that is in use by a Load Balancer results in a"},{"line_number":485,"context_line":"    conflict error (409)."},{"line_number":486,"context_line":""},{"line_number":487,"context_line":"    Deleting a BGP Peer that is associated with a BGP speaker would delete both"},{"line_number":488,"context_line":"    objects."},{"line_number":489,"context_line":""},{"line_number":490,"context_line":"Distributor BGP Speaker API:"},{"line_number":491,"context_line":""},{"line_number":492,"context_line":"* **GET /v2.0/lbaas/distributors/bgp/speakers**"}],"source_content_type":"text/x-rst","patch_set":4,"id":"f26cac96_e8301bd8","line":489,"range":{"start_line":487,"start_character":0,"end_line":489,"end_character":0},"in_reply_to":"9bf93ad6_400df95e","updated":"2026-06-18 13:40:00.000000000","message":"Done","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"da9b67b3950670237a61e17f5346321c9a1860b2","unresolved":true,"context_lines":[{"line_number":542,"context_line":"Loadbalancer API:"},{"line_number":543,"context_line":""},{"line_number":544,"context_line":"* **POST /v2.0/lbaas/loadbalancers**"},{"line_number":545,"context_line":"    Add a new parameter ``distributor_id``."},{"line_number":546,"context_line":""},{"line_number":547,"context_line":"    ``distributor_id`` must be the UUID of a valid BGP Speaker in the current"},{"line_number":548,"context_line":"    implementation."}],"source_content_type":"text/x-rst","patch_set":4,"id":"7720d6c5_be7fb6f9","line":545,"range":{"start_line":545,"start_character":26,"end_line":545,"end_character":40},"updated":"2026-06-05 06:30:10.000000000","message":"TODO: Add a RBAC to restrict the use of distributor_id to specific roles","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"3194a10a7a842831aacd38195bcf60b1bbe2ed53","unresolved":true,"context_lines":[{"line_number":542,"context_line":"Loadbalancer API:"},{"line_number":543,"context_line":""},{"line_number":544,"context_line":"* **POST /v2.0/lbaas/loadbalancers**"},{"line_number":545,"context_line":"    Add a new parameter ``distributor_id``."},{"line_number":546,"context_line":""},{"line_number":547,"context_line":"    ``distributor_id`` must be the UUID of a valid BGP Speaker in the current"},{"line_number":548,"context_line":"    implementation."}],"source_content_type":"text/x-rst","patch_set":4,"id":"d4f27163_cd2d4476","line":545,"range":{"start_line":545,"start_character":26,"end_line":545,"end_character":40},"in_reply_to":"6befae53_b1de6795","updated":"2026-06-18 13:40:00.000000000","message":"I think we should not go to a flavor-only mode, I really need this parameter in POST /loadbalancers","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"3d58bc6545e327791a43977ce576acc884bf94e8","unresolved":true,"context_lines":[{"line_number":542,"context_line":"Loadbalancer API:"},{"line_number":543,"context_line":""},{"line_number":544,"context_line":"* **POST /v2.0/lbaas/loadbalancers**"},{"line_number":545,"context_line":"    Add a new parameter ``distributor_id``."},{"line_number":546,"context_line":""},{"line_number":547,"context_line":"    ``distributor_id`` must be the UUID of a valid BGP Speaker in the current"},{"line_number":548,"context_line":"    implementation."}],"source_content_type":"text/x-rst","patch_set":4,"id":"6befae53_b1de6795","line":545,"range":{"start_line":545,"start_character":26,"end_line":545,"end_character":40},"in_reply_to":"7720d6c5_be7fb6f9","updated":"2026-06-05 14:20:55.000000000","message":"With the current approach of making this functionality very flavor centric, I wonder what\u0027s the value of exposing distributor_id at POST time, while the other AA settings are not.\n\nIs the purpose to allow admins to override the distributor_id in a flavor? If no good reason, maybe is simpler to focus the validation logic at flavor creation time.\n\nNo strong opinion, maybe there are some use cases where this makes sense.\n\nAdditionally, we could consider setting a default distributor_id in config as we do for amp_multi_active_count.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"16f902e90352310c95b0ccaef072129aa5e5b577","unresolved":false,"context_lines":[{"line_number":542,"context_line":"Loadbalancer API:"},{"line_number":543,"context_line":""},{"line_number":544,"context_line":"* **POST /v2.0/lbaas/loadbalancers**"},{"line_number":545,"context_line":"    Add a new parameter ``distributor_id``."},{"line_number":546,"context_line":""},{"line_number":547,"context_line":"    ``distributor_id`` must be the UUID of a valid BGP Speaker in the current"},{"line_number":548,"context_line":"    implementation."}],"source_content_type":"text/x-rst","patch_set":4,"id":"710ceeef_1ff7f338","line":545,"range":{"start_line":545,"start_character":26,"end_line":545,"end_character":40},"in_reply_to":"d4f27163_cd2d4476","updated":"2026-06-19 09:09:03.000000000","message":"Fine, no problem. Let\u0027s keep it in POST /loadbalancers.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"3d58bc6545e327791a43977ce576acc884bf94e8","unresolved":true,"context_lines":[{"line_number":561,"context_line":"    topology. Overrides global ``controller_worker.amp_multi_active_count``"},{"line_number":562,"context_line":"    configuration."},{"line_number":563,"context_line":""},{"line_number":564,"context_line":"    Example flavor metadata::"},{"line_number":565,"context_line":""},{"line_number":566,"context_line":"        {"},{"line_number":567,"context_line":"          \"loadbalancer_topology\": \"MULTI_ACTIVE\","}],"source_content_type":"text/x-rst","patch_set":4,"id":"0d368179_fb723c17","line":564,"updated":"2026-06-05 14:20:55.000000000","message":"TODO: Add distributor_id.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":38562,"name":"Richard Cruise","email":"rcruise@redhat.com","username":"rcruise"},"tag":"autogenerated:claude-review","change_message_id":"1584465d5ad7c960856d07f3fdbee33d58f63928","unresolved":false,"context_lines":[{"line_number":829,"context_line":"* `BFD RFC 5880 \u003chttps://tools.ietf.org/html/rfc5880\u003e`_"},{"line_number":830,"context_line":"* `ECMP and BGP Multipath"},{"line_number":831,"context_line":"  \u003chttps://tools.ietf.org/html/rfc4760\u003e`_"},{"line_number":832,"context_line":"  p"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9135caf4_0a8c2bc1","line":832,"updated":"2026-06-04 08:22:30.000000000","message":"Dangling `p` character at the end of the file — editing\n  artifact that will render as a stray paragraph.","commit_id":"48ed2f50021e2118393df37c7cf1198dfbd73b4b"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"a1483143b0d3eaa55867c8d3b50c10f4a28aa16e","unresolved":true,"context_lines":[{"line_number":56,"context_line":"* The distributor control plane function (*bgp speaker*) runs inside the"},{"line_number":57,"context_line":"  amphora and leverages the existing amphora lifecycle manager."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* Each amphora runs FRR as a *bgp speaker* in the default"},{"line_number":60,"context_line":"  namespace in order to announce the anycast VIP into the L3 fabric. BGP"},{"line_number":61,"context_line":"  peering and announcements occur over a dedicated network (the distributor"},{"line_number":62,"context_line":"  network), or optionally over the management network. The anycast VIP is"},{"line_number":63,"context_line":"  advertised as a /32 or /128 route with a next-hop of the front-end IP"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ef3fd6fc_04df0be2","line":60,"range":{"start_line":59,"start_character":50,"end_line":60,"end_character":11},"updated":"2026-06-08 06:02:12.000000000","message":"we probably need to run FRR in the amphora-haproxy namespace","commit_id":"7211dc96c85ded8d0d8966d01fb568a52f98dd2a"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"9b00fec623948fcc53447fab72f54e29afa210b3","unresolved":true,"context_lines":[{"line_number":56,"context_line":"* The distributor control plane function (*bgp speaker*) runs inside the"},{"line_number":57,"context_line":"  amphora and leverages the existing amphora lifecycle manager."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* Each amphora runs FRR as a *bgp speaker* in the default"},{"line_number":60,"context_line":"  namespace in order to announce the anycast VIP into the L3 fabric. BGP"},{"line_number":61,"context_line":"  peering and announcements occur over a dedicated network (the distributor"},{"line_number":62,"context_line":"  network), or optionally over the management network. The anycast VIP is"},{"line_number":63,"context_line":"  advertised as a /32 or /128 route with a next-hop of the front-end IP"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e4fadf4d_4834f886","line":60,"range":{"start_line":59,"start_character":50,"end_line":60,"end_character":11},"in_reply_to":"ef3fd6fc_04df0be2","updated":"2026-06-08 14:49:52.000000000","message":"Agreed. It aligns as well with a discussion in a previous thread.","commit_id":"7211dc96c85ded8d0d8966d01fb568a52f98dd2a"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"a1483143b0d3eaa55867c8d3b50c10f4a28aa16e","unresolved":true,"context_lines":[{"line_number":59,"context_line":"* Each amphora runs FRR as a *bgp speaker* in the default"},{"line_number":60,"context_line":"  namespace in order to announce the anycast VIP into the L3 fabric. BGP"},{"line_number":61,"context_line":"  peering and announcements occur over a dedicated network (the distributor"},{"line_number":62,"context_line":"  network), or optionally over the management network. The anycast VIP is"},{"line_number":63,"context_line":"  advertised as a /32 or /128 route with a next-hop of the front-end IP"},{"line_number":64,"context_line":"  assigned to the amphora instance (stored in ``amphora.vrrp_ip`` field). The"},{"line_number":65,"context_line":"  front-end network IPs must be directly routable from the L3 fabric, such as"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dc73ec90_76ad1d1e","line":62,"range":{"start_line":62,"start_character":15,"end_line":62,"end_character":53},"updated":"2026-06-08 06:02:12.000000000","message":"I plan to remove this part, I don\u0027t think using the management network for announcements is a good idea.","commit_id":"7211dc96c85ded8d0d8966d01fb568a52f98dd2a"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"9b00fec623948fcc53447fab72f54e29afa210b3","unresolved":true,"context_lines":[{"line_number":59,"context_line":"* Each amphora runs FRR as a *bgp speaker* in the default"},{"line_number":60,"context_line":"  namespace in order to announce the anycast VIP into the L3 fabric. BGP"},{"line_number":61,"context_line":"  peering and announcements occur over a dedicated network (the distributor"},{"line_number":62,"context_line":"  network), or optionally over the management network. The anycast VIP is"},{"line_number":63,"context_line":"  advertised as a /32 or /128 route with a next-hop of the front-end IP"},{"line_number":64,"context_line":"  assigned to the amphora instance (stored in ``amphora.vrrp_ip`` field). The"},{"line_number":65,"context_line":"  front-end network IPs must be directly routable from the L3 fabric, such as"}],"source_content_type":"text/x-rst","patch_set":5,"id":"602bc210_0ca7b411","line":62,"range":{"start_line":62,"start_character":15,"end_line":62,"end_character":53},"in_reply_to":"dc73ec90_76ad1d1e","updated":"2026-06-08 14:49:52.000000000","message":"Linked to the comment about FRR in amphora-haproxy. Would it make sense to rephrase it with the now called frontend network?\n\n\"\"\"\nBGP peering and announcements occur over a dedicated network (the distributor network), or optionally over the **frontend** network.\"\n\"\"\"\n\nIt could offer a basic model for simple environments.","commit_id":"7211dc96c85ded8d0d8966d01fb568a52f98dd2a"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"cf63510515a1bf19caec4e43a0c9ad85f9b3454a","unresolved":true,"context_lines":[{"line_number":476,"context_line":"    * ``description`` (optional)"},{"line_number":477,"context_line":"    * ``admin_state_up`` (optional)"},{"line_number":478,"context_line":""},{"line_number":479,"context_line":"    **Note:** Updating other fields (peer_ip, remote_as, etc.) would require"},{"line_number":480,"context_line":"    updating all load balancers using this BGP Peer - not currently supported."},{"line_number":481,"context_line":""},{"line_number":482,"context_line":"* **DELETE /v2.0/lbaas/distributors/bgp/peers/{peer_id}**"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1bf9fb4f_d348f6ea","line":479,"updated":"2026-06-09 12:45:13.000000000","message":"With the current constraints in the spec, how would operators handle a situation like rotation of passwords? Should something like the following work?\n\nOperator...\n1. ...defines a new peer with the new credentials.\n2. ...updates the speaker with the new peer, and this gets propagated to the amphora.\n3. ...removes the old peer from the speaker, and this gets propagated to amphoras.\n4. ...deletes the old peer.","commit_id":"7211dc96c85ded8d0d8966d01fb568a52f98dd2a"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"7235550cf00d900d1ccd606452f84f933590f5ff","unresolved":true,"context_lines":[{"line_number":476,"context_line":"    * ``description`` (optional)"},{"line_number":477,"context_line":"    * ``admin_state_up`` (optional)"},{"line_number":478,"context_line":""},{"line_number":479,"context_line":"    **Note:** Updating other fields (peer_ip, remote_as, etc.) would require"},{"line_number":480,"context_line":"    updating all load balancers using this BGP Peer - not currently supported."},{"line_number":481,"context_line":""},{"line_number":482,"context_line":"* **DELETE /v2.0/lbaas/distributors/bgp/peers/{peer_id}**"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5e542cd3_7879d80f","line":479,"in_reply_to":"1bf9fb4f_d348f6ea","updated":"2026-06-09 12:58:40.000000000","message":"we haven\u0027t planned that the BGP configuration in the amp could be updated after the creation of the LB (so basically it means that peers and speakers are immutable when used by a LB, the distributor_id of LB is also immutable)\n\nthe most straightforward approach IMHO: we could allow admins to update the creds in the peer, then require them to perform failovers\n\nAn automatic update of LBs when a peer/speaker is updated would be a much more complex work (could be done in a second phase)","commit_id":"7211dc96c85ded8d0d8966d01fb568a52f98dd2a"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"1ea382a623a914d54a6bcfb8d834ffcc0ec62c47","unresolved":true,"context_lines":[{"line_number":476,"context_line":"    * ``description`` (optional)"},{"line_number":477,"context_line":"    * ``admin_state_up`` (optional)"},{"line_number":478,"context_line":""},{"line_number":479,"context_line":"    **Note:** Updating other fields (peer_ip, remote_as, etc.) would require"},{"line_number":480,"context_line":"    updating all load balancers using this BGP Peer - not currently supported."},{"line_number":481,"context_line":""},{"line_number":482,"context_line":"* **DELETE /v2.0/lbaas/distributors/bgp/peers/{peer_id}**"}],"source_content_type":"text/x-rst","patch_set":5,"id":"f061784f_f8218fa3","line":479,"in_reply_to":"5e542cd3_7879d80f","updated":"2026-06-09 13:44:37.000000000","message":"Allowing admins to update the peers and perform failovers look like a reasonable starting point. 👍","commit_id":"7211dc96c85ded8d0d8966d01fb568a52f98dd2a"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"78d5e6e66e846cfe98abc724ed00d42dff5126fb","unresolved":true,"context_lines":[{"line_number":476,"context_line":"    * ``description`` (optional)"},{"line_number":477,"context_line":"    * ``admin_state_up`` (optional)"},{"line_number":478,"context_line":""},{"line_number":479,"context_line":"    **Note:** Updating other fields (peer_ip, remote_as, etc.) would require"},{"line_number":480,"context_line":"    updating all load balancers using this BGP Peer - not currently supported."},{"line_number":481,"context_line":""},{"line_number":482,"context_line":"* **DELETE /v2.0/lbaas/distributors/bgp/peers/{peer_id}**"}],"source_content_type":"text/x-rst","patch_set":5,"id":"d63126b2_67224263","line":479,"in_reply_to":"f061784f_f8218fa3","updated":"2026-06-17 07:33:38.000000000","message":"An other possibility is to use the future load balancer resize API https://review.opendev.org/c/openstack/octavia/+/890215\n(possibility to change the flavor of an existing LB)","commit_id":"7211dc96c85ded8d0d8966d01fb568a52f98dd2a"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"cf63510515a1bf19caec4e43a0c9ad85f9b3454a","unresolved":true,"context_lines":[{"line_number":556,"context_line":""},{"line_number":557,"context_line":"Flavor API:"},{"line_number":558,"context_line":""},{"line_number":559,"context_line":"* **POST /v2.0/lbaas/flavors**"},{"line_number":560,"context_line":"    Add support for ``amp_multi_active_count`` in flavor metadata."},{"line_number":561,"context_line":""},{"line_number":562,"context_line":"    Allows per-flavor configuration of number of amphorae in MULTI_ACTIVE"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f84b01c_dfc2cb01","line":559,"updated":"2026-06-09 12:45:13.000000000","message":"I think this should be a change into the flavorprofiles, right? rather than the flavor API?\n\n```suggestion\n* **POST /v2.0/lbaas/flavorprofiles**\n```","commit_id":"7211dc96c85ded8d0d8966d01fb568a52f98dd2a"},{"author":{"_account_id":5520,"name":"Luis Fernández Álvarez","email":"luis.fernandez.alvarez@cern.ch","username":"luis-fernandez-alvarez"},"change_message_id":"cf63510515a1bf19caec4e43a0c9ad85f9b3454a","unresolved":true,"context_lines":[{"line_number":788,"context_line":""},{"line_number":789,"context_line":"* DevStack-based testing with FRR BGP peer"},{"line_number":790,"context_line":"* Multi-amphora deployment scenarios"},{"line_number":791,"context_line":"* Failover testing"},{"line_number":792,"context_line":"* Session persistence testing across amphorae"},{"line_number":793,"context_line":""},{"line_number":794,"context_line":"**CI/CD:**"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ab3c7117_6b7b2417","line":791,"updated":"2026-06-09 12:45:13.000000000","message":"Thinking about failover procedure in MULTI_ACTIVE topology, there is no change of behviour, right? It\u0027s expected that octavia will go one by one through the amphoras and recycle them.","commit_id":"7211dc96c85ded8d0d8966d01fb568a52f98dd2a"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"3194a10a7a842831aacd38195bcf60b1bbe2ed53","unresolved":true,"context_lines":[{"line_number":120,"context_line":"     ║                   ║            ┌─────────────────────────────┐    ║"},{"line_number":121,"context_line":"     ║                   ║            │     Amphora of Tenant A     │    ║"},{"line_number":122,"context_line":"  ┌──╨──────────┐        ║      ┌────┬┴─────────────────────────────┴┬───╨┐"},{"line_number":123,"context_line":"  │             │        ╠══════╡MGMT│    ns: amphora-haproxy   │f.e.│"},{"line_number":124,"context_line":"  │             │        ║      │ IP ├-----------┬-------------------┤ IP │"},{"line_number":125,"context_line":"  │             │        ║      └────┤    FRR    │    Anycast VIP    ├───╥┘"},{"line_number":126,"context_line":"  │             │        ║           │   (BGP)   │    (loopback)     │   ║"}],"source_content_type":"text/x-rst","patch_set":6,"id":"69218476_20f826c6","line":123,"range":{"start_line":123,"start_character":64,"end_line":123,"end_character":70},"updated":"2026-06-18 13:40:00.000000000","message":"it looks like I cannot count spaces","commit_id":"7f5290ab960e71926f451f72128757d888acfa5c"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"0ceeed19f0ccd93b54efa36c9217edfd53c48028","unresolved":true,"context_lines":[{"line_number":744,"context_line":""},{"line_number":745,"context_line":"**API Versioning:**"},{"line_number":746,"context_line":""},{"line_number":747,"context_line":"* Amphora API version 1.1 introduced for BGP support"},{"line_number":748,"context_line":"* API version negotiation allows mixed amphora versions during upgrades"},{"line_number":749,"context_line":""},{"line_number":750,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":6,"id":"f619e0e8_fd7d4359","line":747,"range":{"start_line":747,"start_character":2,"end_line":747,"end_character":45},"updated":"2026-07-16 07:19:30.000000000","message":"we can probably avoid it, if we change the API version, newly built amphora images won\u0027t work with older control plane","commit_id":"7f5290ab960e71926f451f72128757d888acfa5c"}]}