)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":6577,"name":"Sergey Kraynev","email":"sergejyit@gmail.com","username":"skraynev"},"change_message_id":"5ca3de3ac64c84449106c958382a6d99dfdb82ea","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ed6d56e7_8aa891aa","updated":"2025-03-15 07:10:52.000000000","message":"recheck","commit_id":"d508ec2138d88faf7d6b41ac16bcbedfa4c0a153"},{"author":{"_account_id":6577,"name":"Sergey Kraynev","email":"sergejyit@gmail.com","username":"skraynev"},"change_message_id":"e61edce3a33a274c1bf27b63f2d02361b11f3fd2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"effa73b7_a07fdf5a","updated":"2025-03-15 07:02:28.000000000","message":"recheck octavia-v2-dsvm-scenario-traffic-ops-jobboard timeout","commit_id":"d508ec2138d88faf7d6b41ac16bcbedfa4c0a153"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"da1c4f2d91454265cc2a13106402becf09b71625","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"55a6b4e0_9e89d7c8","updated":"2025-05-13 01:07:04.000000000","message":"I have proposed an alternate patch: https://review.opendev.org/c/openstack/octavia/+/949548","commit_id":"9fd5737afe729ed63e82693c0362e77d7c497a17"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"0487ca3fb67831f121d983e8bf5cc85770d4e385","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"d60ded1a_0fcd160b","updated":"2025-03-28 20:51:57.000000000","message":"I think we can fix this in an cleaner way by correcting the exception handling. There seems to be an unwrapped exception leaking.","commit_id":"9fd5737afe729ed63e82693c0362e77d7c497a17"},{"author":{"_account_id":6577,"name":"Sergey Kraynev","email":"sergejyit@gmail.com","username":"skraynev"},"change_message_id":"141b3f52b925c07e8daaf8b0341cd0ef606fa993","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"53d3916e_be82ad6d","updated":"2025-04-15 15:18:33.000000000","message":"Waiting the alternative fix from johnsomor@gmail.com","commit_id":"9fd5737afe729ed63e82693c0362e77d7c497a17"}],"octavia/common/validate.py":[{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"0487ca3fb67831f121d983e8bf5cc85770d4e385","unresolved":true,"context_lines":[{"line_number":343,"context_line":""},{"line_number":344,"context_line":"def ip_address_is_busy(subnet_id, ip_address, project_id):"},{"line_number":345,"context_line":"    \"\"\"Raises an exception when an ip is used on port.\"\"\""},{"line_number":346,"context_line":"    network_driver \u003d utils.get_network_driver()"},{"line_number":347,"context_line":"    try:"},{"line_number":348,"context_line":"        network_driver.get_port_by_subnet_id_and_ip_address("},{"line_number":349,"context_line":"            subnet_id, ip_address, project_id"}],"source_content_type":"text/x-python","patch_set":3,"id":"b0d8879c_69900b57","line":346,"updated":"2025-03-28 20:51:57.000000000","message":"This creates a race condition as the IP may be allocated after this check.\nWe really should rely on neutron to raise these exceptions as the allocation check is  atomic on the neutron side.","commit_id":"9fd5737afe729ed63e82693c0362e77d7c497a17"},{"author":{"_account_id":6577,"name":"Sergey Kraynev","email":"sergejyit@gmail.com","username":"skraynev"},"change_message_id":"2b3107d15a440e515aa27da9eb32b1a44d20b440","unresolved":true,"context_lines":[{"line_number":343,"context_line":""},{"line_number":344,"context_line":"def ip_address_is_busy(subnet_id, ip_address, project_id):"},{"line_number":345,"context_line":"    \"\"\"Raises an exception when an ip is used on port.\"\"\""},{"line_number":346,"context_line":"    network_driver \u003d utils.get_network_driver()"},{"line_number":347,"context_line":"    try:"},{"line_number":348,"context_line":"        network_driver.get_port_by_subnet_id_and_ip_address("},{"line_number":349,"context_line":"            subnet_id, ip_address, project_id"}],"source_content_type":"text/x-python","patch_set":3,"id":"09c57b7a_b3673e31","line":346,"in_reply_to":"b0d8879c_69900b57","updated":"2025-03-31 07:09:45.000000000","message":"Agree.\nAs I see, there are several potential cases:\n- address is busy and validation correctly identify it\n- address was removed during validation - validation incorrectly raises error, but second try of creation will pass (looks like acceptable behaviour)\n- address created after passing validation. In this case original Neutron error will raise error. (creation aborted too, but with different error)\n\nFor me the last case will happen really rare. So it could be ignored.\n\nRegarding your suggestion: could you please explain what did you suggest?\n\nWithout validation we catch exception here: https://github.com/openstack/octavia/blob/4db66dd06d0f0cb9fae427b6b53d92ae2851c118/octavia/network/drivers/neutron/allowed_address_pairs.py#L541-L548\nAnd reraise it with original STATUS_CODE. So for neutron it\u0027s 500.\nAs I understand, raising 400 code is better here and also allow to avoid traceback in neutron with 500 error code.","commit_id":"9fd5737afe729ed63e82693c0362e77d7c497a17"}]}