)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"1fddfa718ff78edcbdb7585d22d2d02192672009","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"6298fade_27c8442f","updated":"2025-09-19 15:42:56.000000000","message":"I don\u0027t think this is a good approach.\n\n1. Adding a task to the forward flow (normal path) that attempts to do error handling is an anti-pattern. It was added to the normal LB create flow, amphora failover flow, and LB failover flows. This means we are extending the runtime of those flows for an issue that will not occur 99.9% (if not more) of the time. It will always incur the overhead of another task and will always do a round trip to the database.\n2. It\u0027s also not clear we are targeting the specific provisioning ERROR situations that could lead to split-brain. There are many other places in the code that can move an amphora into ERROR. I think we need to evaluate all of them to determine if they could lead to a mis-configuration that would cause a split brain (a quick count indicated over 14 other places).\n3. I am wondering if the failure situations don\u0027t call for a more heavy handed STONITH approach We know nova can do odd things and resurrect failed server instances (i.e, due to hardware outages) so we might want to take this up a notch and be more forceful about handling nova failures.\n\nThe bug report scenario is a bit artificial, so it\u0027s hard to fully understand how someone got into this situation.\n\nWe need to be super careful with the amphora state machines as we need to make sure we don\u0027t \"disable\" fully working amphora instances that may be serving traffic.\n\nThis may be a good PTG topic to discuss.\nI think we need to identify all of the places an Amphora could go into prov ERROR and evaluate if leaving the Amphora instance in place is safe or if other actions should be taken.\nWe should also put back together the Amphora VRRP state matrix to help understand where a possible split-brain could happen.","commit_id":"6ae4cfbc22727e586053fbe8b752d40b39d7bf46"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"cc6485b8558fbf344fdd7587b9f121e3f2bb06e7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"b0543f9e_707c5c7f","in_reply_to":"6298fade_27c8442f","updated":"2025-09-22 08:25:37.000000000","message":"2. right, we are not changing the way Octavia moves amphora into ERROR, we only change the flow of an amphora failover when the \"peer\" amphora is already in ERROR","commit_id":"6ae4cfbc22727e586053fbe8b752d40b39d7bf46"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"e341a73acdfa86645ec1dbf1785e245c971c2cb6","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"41df2426_042374a2","in_reply_to":"b0543f9e_707c5c7f","updated":"2025-09-23 08:37:42.000000000","message":"What about blocking automated failovers of load balancer when the peer amphora in ERROR status?\n\n1. when an amphora is in ERROR, automated failover is disabled, it means that an admin will have to perform a failover anyway.\n\n2. when an amphora is in ERROR, if a failover is performed on the 2nd amphora, the LB is moved from provisioning_status ERROR to ACTIVE, which gives the impression that the status is fine but the LB is not fully functional (no HA) and this info is not available to the users (they don\u0027t see the status of the amphorae).\n\n3. the API blocks failovers of amphorae that belong to LBs with a provisioning_status ERROR, we could do the same in the health-manager to be more consistent.\n\n4. creating a new amphora (during a failover) while the other amphora is in ERROR triggers this split-brain behavior with VRRP.","commit_id":"6ae4cfbc22727e586053fbe8b752d40b39d7bf46"}]}