)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":32053,"name":"Denys Mishchenko","email":"denis@mischenko.org.ua","username":"arddennis"},"change_message_id":"e4fa59d12327e1c047ef10ee49cc35cb7432ae0f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":44,"id":"0d6826bd_6d082361","updated":"2022-12-19 07:30:10.000000000","message":"recheck","commit_id":"79b90722b277dac051a9a8d96be84d70d0cdfeaa"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"101b57d0c4f96268945aed4abd7f2f21d1345fbf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":46,"id":"dfd4c209_7513b4fe","updated":"2023-03-28 13:33:02.000000000","message":"Folks, what about failover ? Is it working out-of-the-box with this patch or not ? ","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"f2fbc4188ec2f2716b79f50919461da367afd7f5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":46,"id":"3b4392ec_b9140c4a","updated":"2023-03-27 17:13:06.000000000","message":"This works for us, and tempest tests exist and passing with these change.\n\nTempest patch link: https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/868868","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"f332993731d6cf98eae01e4b2f3a4f5dd30d9447","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":46,"id":"10acca88_13fd263c","updated":"2023-03-28 14:44:50.000000000","message":"We should also remove amphora_v1 path and rebase on top of https://review.opendev.org/q/topic:amphorav1-removal\n\nDocs change is needed to reflect on how to use that and requirements (like stretched network across AZs).","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"a27248a40f0a380a474e27144bac66f883abe0c8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":46,"id":"4ccc9785_ab1c139d","updated":"2023-03-28 14:38:39.000000000","message":"What happens here when a user specifies a specific AZ for the load balancer, but the flavor also splits the load balancer across AZs?","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"323df3b09bf1c696b52f2a98fb0da6b3db522ce1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":46,"id":"b263d67b_e2970f02","in_reply_to":"65e50ccd_5dc8aac5","updated":"2023-03-28 14:23:11.000000000","message":"Okay, let\u0027s say amphora is failed on compute in az1, compute host in az1 is down and i want to call failover on that failed amphora. How is it ensured that another new instance of amphora will land right az ?","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"f1a4b2d0e390b9934e3240ec4a106e331fbc72e0","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":46,"id":"8313de37_f81c6b33","in_reply_to":"77b9fe6a_5f967f37","updated":"2023-03-28 15:40:41.000000000","message":"The problem is what will happen if you call failover on amphora (Link to api reference https://docs.openstack.org/api-ref/load-balancer/v2/?expanded\u003dfailover-amphora-detail#failover-amphora ). Because it will call another flow: get_failover_amphora_flow and I don\u0027t think it will honor the AZ that was selected initially.","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":29268,"name":"Matthew Heler","email":"matthew.heler@hotmail.com","username":"mheler"},"change_message_id":"bb401df7c59e5bb5758ccde86129c9986c8f08f8","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":46,"id":"efffd930_e583dbb8","in_reply_to":"8313de37_f81c6b33","updated":"2024-03-12 04:08:12.000000000","message":"openstack loadbalancer amphora list --long -c id -c role -c cached_zone -f value --loadbalancer d5ad43dc-2df9-41f9-a1b8-5cbd27dcd564\n870ef17e-7e27-4b01-9e15-23ee66ee50d9 BACKUP infralab-az1\n4b69101e-aca0-44b0-9c40-964e27ad8ec0 MASTER infralab-az2\n\nopenstack loadbalancer fail --wait d5ad43dc-2df9-41f9-a1b8-5cbd27dcd564\n\nopenstack loadbalancer amphora list --long -c id -c role -c cached_zone -f value --loadbalancer d5ad43dc-2df9-41f9-a1b8-5cbd27dcd564\na00c79ea-3101-4910-a18b-17216770836d BACKUP infralab-az2\n20da3714-0625-4c21-aee4-a3bc325c8617 MASTER infralab-az1\n\nMy setup is a two AZ OpenStack deployment, for my use-case this is \"good enough\". But it doesn\u0027t appear that the AZs selected initially are honored on a fail over, however it does appear they land on different AZs.","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":32053,"name":"Denys Mishchenko","email":"denis@mischenko.org.ua","username":"arddennis"},"change_message_id":"3de6d8062a904caf2c26417474bdd89f6bab9b54","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":46,"id":"77b9fe6a_5f967f37","in_reply_to":"b263d67b_e2970f02","updated":"2023-03-28 14:47:50.000000000","message":"Once you create an active-standby setup, you have two amphoraes up and running. One is master, second is backup. Master AZ is calculated based on a hash of loadbalancer id. ID is the same on both master and backup, so hash is reproducible and ensures that they use different AZs at the beginning. As for the single amphora deployment, there is no point to choose another AZ on a failover, you may need to define the only and separate AZ for amphoras or don\u0027t use them at all. \n\nHere is a live scenario:\nWe have two racks of compute servers. The first rack is in AZ1, the second - AZ2. Lets say an ATS switch dies in one of the racks. Using active-standby you can be in the situation when both master and backup amphoras are in the same rack, but on different compute nodes. With availability-zones, you can have master in AZ2 and backup in AZ1 which are different racks.","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"ff55c07b570a798a8ee3de243867e66955bf0109","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":46,"id":"65e50ccd_5dc8aac5","in_reply_to":"dfd4c209_7513b4fe","updated":"2023-03-28 14:08:28.000000000","message":"Yep, it\u0027s regular Active/Standby setup, except Octavia will ensure that amphoras will land in different AZs.\nThough, as a requirement here you must have networks being stretched through AZs - it doesn\u0027t include implementation of BGP or whatsoever.","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":32053,"name":"Denys Mishchenko","email":"denis@mischenko.org.ua","username":"arddennis"},"change_message_id":"0de795223438e7efb452a4bc86b66c801d771980","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":46,"id":"175b91a3_c6608d1c","in_reply_to":"efffd930_e583dbb8","updated":"2024-03-13 10:31:28.000000000","message":"Matthew, I didn\u0027t found enough concentration to finish this, but I have a workaround to offer. It is possible to get list of current amphoras from the amphora_repo. The one we intend to failover will be marked as PENDING_DELETE You can take a look how it was implemented in my tests lab: \nhttps://github.com/openstack/octavia/compare/master...citynetwork:octavia:availability_zones#diff-7e12c5466b5ccd33e3f1cf6693d1ac074717faddad37c01a547dc3e1d8c27332R248\nFor me failover works correctly all the time as it happens in exactly the same AZ where previous was placed.","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":36250,"name":"Przemysław Kuczyński","display_name":"przemekk","email":"przemyslaw.kuczynski@ochk.pl","username":"przemekk"},"change_message_id":"c0e551561cae0392a2fc35ccc53a77ff59136c5a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":49,"id":"d6268dd1_373bf1c2","updated":"2025-12-10 17:13:55.000000000","message":"Any updates on this . When it will be approved","commit_id":"7df248aa4f2a9e41b2d1c7c9697faa6b512c7c9e"},{"author":{"_account_id":27256,"name":"Vadim Ponomarev","email":"velizarx@gmail.com","username":"velizarx"},"change_message_id":"fb07902356da6dfe526b6157558d0e878f3f2ab2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":49,"id":"5500f1db_aa8e4b8d","updated":"2024-07-12 13:04:09.000000000","message":"Hi folks! I want to resurrect this change and implement version of Denys Mishchenko from his last comment. His version contains fixes for failover and works with multiple AZs as expected. Also, he splitted compute AZs and Octavia AZs to avoid confusion. I just changed release notes and rebased his change to latest master commit.","commit_id":"7df248aa4f2a9e41b2d1c7c9697faa6b512c7c9e"},{"author":{"_account_id":27256,"name":"Vadim Ponomarev","email":"velizarx@gmail.com","username":"velizarx"},"change_message_id":"5688adc3d91daf5c6ae45a16f14b8151b8ed892b","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":49,"id":"1f96688b_bfc87161","updated":"2024-07-12 13:09:54.000000000","message":"It’s an interesting coincidence that I re-rebased the patch a day after you transferred it by yourself ;). Ok, then I\u0027ll join your change.","commit_id":"7df248aa4f2a9e41b2d1c7c9697faa6b512c7c9e"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"6c5b8deb86b4d2c982aff7b417684e00112145af","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":49,"id":"63eabd20_948eb945","updated":"2024-07-12 13:03:29.000000000","message":"We\u0027re working on a blueprint and posted the code here as a WIP patch: https://review.opendev.org/c/openstack/octavia/+/923939\n\nSo I think we should really go through the spec discussion first, and, potentially abandon this patch once it will be done.","commit_id":"7df248aa4f2a9e41b2d1c7c9697faa6b512c7c9e"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"cb64b4a13f6abfd9af1cd592192ce9ed34a67829","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":49,"id":"81ecbd48_d1a529dc","in_reply_to":"20f14ad9_3cebb664","updated":"2025-12-11 08:06:23.000000000","message":"@noonedeadpunk@gmail.com do you think there\u0027s a chance that the nova feature will be included in the 2026.1 release?","commit_id":"7df248aa4f2a9e41b2d1c7c9697faa6b512c7c9e"},{"author":{"_account_id":27256,"name":"Vadim Ponomarev","email":"velizarx@gmail.com","username":"velizarx"},"change_message_id":"5688adc3d91daf5c6ae45a16f14b8151b8ed892b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":49,"id":"7d2ecda7_09d6a1c1","in_reply_to":"31385971_979b7a03","updated":"2024-07-12 13:09:54.000000000","message":"It’s an interesting coincidence that I re-rebased the patch a day after you transferred it by yourself ;). Ok, then I\u0027ll join your change.","commit_id":"7df248aa4f2a9e41b2d1c7c9697faa6b512c7c9e"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"37ab919c8a03b55f94849447c58c98ddaff17e21","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":49,"id":"31385971_979b7a03","in_reply_to":"5500f1db_aa8e4b8d","updated":"2024-07-12 13:07:31.000000000","message":"Please join the discussion on the blueprint: https://review.opendev.org/c/openstack/octavia/+/923571/\n\nand actually a new patch was created:\nhttps://review.opendev.org/c/openstack/octavia/+/923939\n\nReviews on these as well as some testing are really very appreciated and matter!","commit_id":"7df248aa4f2a9e41b2d1c7c9697faa6b512c7c9e"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"32e38e8c8d552b871dc00e496ff2327579f22e9d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":49,"id":"20f14ad9_3cebb664","in_reply_to":"9b06e49d_765f2001","updated":"2025-12-10 18:01:46.000000000","message":"Frankly - I think we should do https://review.opendev.org/c/openstack/nova-specs/+/900296 and then use the new policy in Octavia, which would be extremely trivial to do.","commit_id":"7df248aa4f2a9e41b2d1c7c9697faa6b512c7c9e"},{"author":{"_account_id":29244,"name":"Gregory Thiemonge","email":"gthiemon@redhat.com","username":"gthiemonge"},"change_message_id":"5a39a187a62654a0de919c3df769f34f16ae4013","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":49,"id":"9b06e49d_765f2001","in_reply_to":"d6268dd1_373bf1c2","updated":"2025-12-10 17:52:11.000000000","message":"it looks like this proposal has been abandonned and replaced by https://review.opendev.org/c/openstack/octavia/+/923939","commit_id":"7df248aa4f2a9e41b2d1c7c9697faa6b512c7c9e"}],"etc/octavia.conf":[{"author":{"_account_id":15309,"name":"zhaobo","email":"bzhaojyathousandy@gmail.com","username":"ZhaoBo"},"change_message_id":"769370a75bbf06459a7db864ab96836466ac2cd5","unresolved":false,"context_lines":[{"line_number":366,"context_line":"# Otherwise, the default name format will be used: \"amphora-{UUID}\"."},{"line_number":367,"context_line":"# random_amphora_name_length \u003d 0"},{"line_number":368,"context_line":""},{"line_number":369,"context_line":"# Availability zone to use for creating Amphorae"},{"line_number":370,"context_line":"# availability_zone \u003d"},{"line_number":371,"context_line":""},{"line_number":372,"context_line":"# Can nova accept a CSV list of availability zones? Note: this requires a patch"},{"line_number":373,"context_line":"# to the scheduler that some providers use but is not merged upstream."}],"source_content_type":"text/plain","patch_set":24,"id":"3f79a3b5_24e01097","line":370,"range":{"start_line":369,"start_character":0,"end_line":370,"end_character":21},"updated":"2018-09-20 07:25:21.000000000","message":"Is that necessary to change this option from availability_zone to availability_zones ?","commit_id":"3bf9211414549306dec24e7f6001ab12542cf238"}],"octavia/api/drivers/amphora_driver/flavor_schema.py":[{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"a27248a40f0a380a474e27144bac66f883abe0c8","unresolved":true,"context_lines":[{"line_number":48,"context_line":"            \"type\": \"string\","},{"line_number":49,"context_line":"            \"description\": \"The amphora image tag.\""},{"line_number":50,"context_line":"        },"},{"line_number":51,"context_line":"        consts.AVAILABILITY_ZONE: {"},{"line_number":52,"context_line":"            \"type\": \"array\","},{"line_number":53,"context_line":"            \"description\": \"Availability zone for amphora\""},{"line_number":54,"context_line":"        }"}],"source_content_type":"text/x-python","patch_set":46,"id":"4208d546_343de127","line":51,"updated":"2023-03-28 14:38:39.000000000","message":"We already have availability zones, so we should change this to be \"AVAILABILITY_ZONES\" or something more clear to differentiate this from the existing availability zone feature.","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":27256,"name":"Vadim Ponomarev","email":"velizarx@gmail.com","username":"velizarx"},"change_message_id":"fb07902356da6dfe526b6157558d0e878f3f2ab2","unresolved":false,"context_lines":[{"line_number":48,"context_line":"            \"type\": \"string\","},{"line_number":49,"context_line":"            \"description\": \"The amphora image tag.\""},{"line_number":50,"context_line":"        },"},{"line_number":51,"context_line":"        consts.AVAILABILITY_ZONE: {"},{"line_number":52,"context_line":"            \"type\": \"array\","},{"line_number":53,"context_line":"            \"description\": \"Availability zone for amphora\""},{"line_number":54,"context_line":"        }"}],"source_content_type":"text/x-python","patch_set":46,"id":"ca9b204f_a042df5b","line":51,"in_reply_to":"4208d546_343de127","updated":"2024-07-12 13:04:09.000000000","message":"Implementation was changed","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"a27248a40f0a380a474e27144bac66f883abe0c8","unresolved":true,"context_lines":[{"line_number":50,"context_line":"        },"},{"line_number":51,"context_line":"        consts.AVAILABILITY_ZONE: {"},{"line_number":52,"context_line":"            \"type\": \"array\","},{"line_number":53,"context_line":"            \"description\": \"Availability zone for amphora\""},{"line_number":54,"context_line":"        }"},{"line_number":55,"context_line":"    }"},{"line_number":56,"context_line":"}"}],"source_content_type":"text/x-python","patch_set":46,"id":"ddb7eddb_6638989c","line":53,"updated":"2023-03-28 14:38:39.000000000","message":"Same here, this needs to be updated.","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"},{"author":{"_account_id":27256,"name":"Vadim Ponomarev","email":"velizarx@gmail.com","username":"velizarx"},"change_message_id":"fb07902356da6dfe526b6157558d0e878f3f2ab2","unresolved":false,"context_lines":[{"line_number":50,"context_line":"        },"},{"line_number":51,"context_line":"        consts.AVAILABILITY_ZONE: {"},{"line_number":52,"context_line":"            \"type\": \"array\","},{"line_number":53,"context_line":"            \"description\": \"Availability zone for amphora\""},{"line_number":54,"context_line":"        }"},{"line_number":55,"context_line":"    }"},{"line_number":56,"context_line":"}"}],"source_content_type":"text/x-python","patch_set":46,"id":"41317f6e_eca16c61","line":53,"in_reply_to":"ddb7eddb_6638989c","updated":"2024-07-12 13:04:09.000000000","message":"Implementation was changed","commit_id":"a2f34bb311b8950c784c35ed61d407b475630140"}],"octavia/compute/drivers/nova_driver.py":[{"author":{"_account_id":15309,"name":"zhaobo","email":"bzhaojyathousandy@gmail.com","username":"ZhaoBo"},"change_message_id":"769370a75bbf06459a7db864ab96836466ac2cd5","unresolved":false,"context_lines":[{"line_number":127,"context_line":"            try:"},{"line_number":128,"context_line":"                availability_zone \u003d availability_zone[0]"},{"line_number":129,"context_line":"            except IndexError:"},{"line_number":130,"context_line":"                availability_zone \u003d None"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"        try:"},{"line_number":133,"context_line":"            network_ids \u003d network_ids or []"}],"source_content_type":"text/x-python","patch_set":24,"id":"3f79a3b5_7267a652","line":130,"range":{"start_line":130,"start_character":16,"end_line":130,"end_character":40},"updated":"2018-09-20 07:25:21.000000000","message":"I think we need a log here.","commit_id":"3bf9211414549306dec24e7f6001ab12542cf238"}],"octavia/controller/worker/flows/amphora_flows.py":[{"author":{"_account_id":28067,"name":"Patrik Martinsson","email":"martinsson.patrik@gmail.com","username":"patchon"},"change_message_id":"a2de71d3937674124eb0ccacf638a3cfb50402b3","unresolved":false,"context_lines":[{"line_number":123,"context_line":"        require_server_group_id_condition \u003d ("},{"line_number":124,"context_line":"            role in (constants.ROLE_BACKUP, constants.ROLE_MASTER) and"},{"line_number":125,"context_line":"            CONF.nova.enable_anti_affinity)"},{"line_number":126,"context_line":"        require_availability_zone_condition \u003d ("},{"line_number":127,"context_line":"            role in (constants.ROLE_BACKUP, constants.ROLE_MASTER) and"},{"line_number":128,"context_line":"            len(CONF.nova.availability_zone) \u003e 1)"},{"line_number":129,"context_line":""}],"source_content_type":"text/x-python","patch_set":25,"id":"3f79a3b5_ba87c5b3","line":126,"updated":"2018-11-04 13:29:53.000000000","message":"When an amphora gets *re*created (that is *not* using a spare-amp) we have an issue with this code, since the role in that case is set to ROLE_STANDALONE. \n\nThis means that we will never use the multi-az-requirement when recreating amps. This was the issue I was hitting when commenting on this patch earlier, you can see the logs here http://paste.openstack.org/show/728729/ \n\nSo what happens is that the log message I was referring to is actually *only* from the \"flow\" when looking for spare-amps, *but when* we don\u0027t have any spare-amps, and we get to L394, we specifically call the function \u0027 get_amphora_for_lb_subflow\u0027 without any role set (it\u0027s commented in the code that it will be updated at a later point) which will make it default to ROLE_STANDALONE and thus this section wont have any affect. \n\nSince I\u0027m not to familiar with the code, I\u0027m not really sure what the proper workaround would be (either call the function with the correct role set (but I assume its unknown at that point since its not there to begin with), or change this part of the code). \n\nThe way I solved it was to just add \u0027constants.ROLE_STANDALONE\u0027 to this if-statement. Not really sure if that will have any side-effects yet, but I can confirm that the code works as intended now. \n\nAmp\u0027s are properly being placed in separate az\u0027s, both at \"creation\" and \"recreation\".   \n\nTook me quite a while to figure this one out - anyways, great job with this patch!","commit_id":"c1b1a5426732621d8c4ac8535c768b98ac9dc3f7"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"4d09d3970cfa37cd1564f23c5bc4588efcd47d92","unresolved":false,"context_lines":[{"line_number":123,"context_line":"        require_server_group_id_condition \u003d ("},{"line_number":124,"context_line":"            role in (constants.ROLE_BACKUP, constants.ROLE_MASTER) and"},{"line_number":125,"context_line":"            CONF.nova.enable_anti_affinity)"},{"line_number":126,"context_line":"        require_availability_zone_condition \u003d ("},{"line_number":127,"context_line":"            role in (constants.ROLE_BACKUP, constants.ROLE_MASTER) and"},{"line_number":128,"context_line":"            len(CONF.nova.availability_zone) \u003e 1)"},{"line_number":129,"context_line":""}],"source_content_type":"text/x-python","patch_set":25,"id":"3f79a3b5_64389aca","line":126,"in_reply_to":"3f79a3b5_ba87c5b3","updated":"2018-11-05 21:55:43.000000000","message":"Yeah, thought about it a bit and I *hate* saying this, but the complexity in these flows is such that I think fixing the real issue (the fact that L394 just ignores the passed role) is probably more dangerous/disruptive than just letting the AZ code run on any type of amp. So, even though this is not something I will ever run into (since I use a spares pool -- highly recommended) I will just make that correction here and it should be fine.","commit_id":"c1b1a5426732621d8c4ac8535c768b98ac9dc3f7"}],"octavia/controller/worker/tasks/amphora_driver_tasks.py":[{"author":{"_account_id":10850,"name":"German Eichberger","email":"german.eichberger@gmail.com","username":"german"},"change_message_id":"38a1deab68bdfddb9f2430fdc795b21ba2b54d46","unresolved":false,"context_lines":[{"line_number":346,"context_line":"        return random.choice(available_zones)"},{"line_number":347,"context_line":""},{"line_number":348,"context_line":""},{"line_number":349,"context_line":"class PickSpareAmphoraZones(BaseAmphoraTask):"},{"line_number":350,"context_line":"    def execute(self):"},{"line_number":351,"context_line":"        conf_zones \u003d CONF.nova.availability_zone"},{"line_number":352,"context_line":""}],"source_content_type":"text/x-python","patch_set":12,"id":"5f7c97a3_afc53c90","line":349,"updated":"2018-05-23 17:35:48.000000000","message":"This method is superfluous - nova will automatically pick an az with sufficient resources when no AZ is specified. Since this relies on the assumption that should balance amps between AZs it\u0027s dangerous if an operator has AZs with vastly different capacity -- personally would have nova pick the AZ by leaving it blank for spares","commit_id":"28b8046ecdb171f25145b6d9df8af066b1994277"},{"author":{"_account_id":15309,"name":"zhaobo","email":"bzhaojyathousandy@gmail.com","username":"ZhaoBo"},"change_message_id":"769370a75bbf06459a7db864ab96836466ac2cd5","unresolved":false,"context_lines":[{"line_number":391,"context_line":"        # Subtract the used zones from the available zones"},{"line_number":392,"context_line":"        available_zones \u003d list(set(conf_zones) - set(used_zones))"},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"        LOG.debug(\"Trying to make an amphora in one of the following AZs: %s\","},{"line_number":395,"context_line":"                  available_zones)"},{"line_number":396,"context_line":"        if CONF.nova.accepts_multiple_az:"},{"line_number":397,"context_line":"            # Shuffle the result so we don\u0027t weight towards the front"}],"source_content_type":"text/x-python","patch_set":24,"id":"3f79a3b5_2d89d3c5","line":394,"range":{"start_line":394,"start_character":68,"end_line":394,"end_character":69},"updated":"2018-09-20 07:25:21.000000000","message":"configured?","commit_id":"3bf9211414549306dec24e7f6001ab12542cf238"},{"author":{"_account_id":15309,"name":"zhaobo","email":"bzhaojyathousandy@gmail.com","username":"ZhaoBo"},"change_message_id":"769370a75bbf06459a7db864ab96836466ac2cd5","unresolved":false,"context_lines":[{"line_number":416,"context_line":"        for amp in spare_amps:"},{"line_number":417,"context_line":"            # We\u0027re only going to record for configured zones..."},{"line_number":418,"context_line":"            if amp.cached_zone in zones:"},{"line_number":419,"context_line":"                zones[amp.cached_zone] +\u003d 1"},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"        # We could just get the minimum key, but that is deterministic if there"},{"line_number":422,"context_line":"        # are multiple zones with the same usage, which will lead to a stampede"}],"source_content_type":"text/x-python","patch_set":24,"id":"3f79a3b5_4d88cfc4","line":419,"range":{"start_line":419,"start_character":1,"end_line":419,"end_character":43},"updated":"2018-09-20 07:25:21.000000000","message":"There is a case if we change the configured AZs from \"A,B,C\" to \"A,B\". The dict which use for counting in L409, is based on the configured AZs, but we count by amp\u0027s db records. So if we had lauched a loadbalancer before we change from \"A,B,C\" to \"A,B\", and a amp in C for this loadbalancer. How we treat this case? Maybe using the failover mechisim? delete the amp in C?","commit_id":"3bf9211414549306dec24e7f6001ab12542cf238"}],"octavia/controller/worker/tasks/database_tasks.py":[{"author":{"_account_id":15309,"name":"zhaobo","email":"bzhaojyathousandy@gmail.com","username":"ZhaoBo"},"change_message_id":"769370a75bbf06459a7db864ab96836466ac2cd5","unresolved":false,"context_lines":[{"line_number":511,"context_line":"            for a in lb.amphorae:"},{"line_number":512,"context_line":"                if a.status not in used_statuses:"},{"line_number":513,"context_line":"                    used_zones.append(a.cached_zone)"},{"line_number":514,"context_line":""},{"line_number":515,"context_line":"            LOG.debug(\"Load balancer is already using the following zones: %s\","},{"line_number":516,"context_line":"                      used_zones)"},{"line_number":517,"context_line":""}],"source_content_type":"text/x-python","patch_set":24,"id":"3f79a3b5_32bcceb3","line":514,"updated":"2018-09-20 07:25:21.000000000","message":"if used_zones: then log","commit_id":"3bf9211414549306dec24e7f6001ab12542cf238"},{"author":{"_account_id":15309,"name":"zhaobo","email":"bzhaojyathousandy@gmail.com","username":"ZhaoBo"},"change_message_id":"769370a75bbf06459a7db864ab96836466ac2cd5","unresolved":false,"context_lines":[{"line_number":520,"context_line":"            # Shuffle the result so we don\u0027t weight towards the front"},{"line_number":521,"context_line":"            random.shuffle(available_zones)"},{"line_number":522,"context_line":""},{"line_number":523,"context_line":"            LOG.debug(\"Trying to allocate an amphora in one of these AZs: %s\","},{"line_number":524,"context_line":"                      available_zones)"},{"line_number":525,"context_line":"            # Return the first amp we can get"},{"line_number":526,"context_line":"            for zone in available_zones:"}],"source_content_type":"text/x-python","patch_set":24,"id":"3f79a3b5_92e282d3","line":523,"range":{"start_line":523,"start_character":63,"end_line":523,"end_character":68},"updated":"2018-09-20 07:25:21.000000000","message":"configured?","commit_id":"3bf9211414549306dec24e7f6001ab12542cf238"}],"octavia/db/repositories.py":[{"author":{"_account_id":15309,"name":"zhaobo","email":"bzhaojyathousandy@gmail.com","username":"ZhaoBo"},"change_message_id":"769370a75bbf06459a7db864ab96836466ac2cd5","unresolved":false,"context_lines":[{"line_number":942,"context_line":"            if amp is None:"},{"line_number":943,"context_line":"                return None"},{"line_number":944,"context_line":"            if zone:"},{"line_number":945,"context_line":"                LOG.debug(\"Found amp: %s in %s\", amp.id, amp.cached_zone)"},{"line_number":946,"context_line":""},{"line_number":947,"context_line":"            amp.status \u003d \u0027ALLOCATED\u0027"},{"line_number":948,"context_line":"            amp.load_balancer_id \u003d load_balancer_id"}],"source_content_type":"text/x-python","patch_set":24,"id":"3f79a3b5_04f39474","line":945,"range":{"start_line":945,"start_character":27,"end_line":945,"end_character":46},"updated":"2018-09-20 07:25:21.000000000","message":"Found amp \u003cID\u003e in available zone \u003cZONE\u003e? This log is too simple. ;-)","commit_id":"3bf9211414549306dec24e7f6001ab12542cf238"}]}