)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":13192,"name":"Souville","display_name":"Bertrand Souville","email":"souville@docomolab-euro.com","username":"bertys"},"change_message_id":"1e9b5687e7eac5eca1e5ae75ce4681a94d0b960f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":7,"id":"b2d612a7_ccb92a14","updated":"2026-05-22 13:33:09.000000000","message":"recheck - seems unrelated failure","commit_id":"fea549a77a0e0970796fa1377a6e4d872cec2a52"},{"author":{"_account_id":25701,"name":"Yasufumi Ogawa","email":"yasufum.o@gmail.com","username":"yasufum"},"change_message_id":"3a09f2d304731b59cd16933979b20cd80e277f1e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"5495dd57_606f3d30","updated":"2026-08-08 08:46:04.000000000","message":"Thank you for your fix. Sorry for the late response since I\u0027ve tried to resolve our zuul tests not stable. Please check my comments.","commit_id":"b23be152001ae9bcc96aba9dc81cde5be915b748"}],"tacker/sol_refactored/infra_drivers/openstack/nova_utils.py":[{"author":{"_account_id":36672,"name":"Shivam Shukla","display_name":"Shivam Shukla","email":"shivam.shukla3@india.nec.com","username":"shivam.shukla3"},"change_message_id":"fed05acd4b3afaeafda8f9f6faea5cd0d13a0f00","unresolved":true,"context_lines":[{"line_number":78,"context_line":"                LOG.debug(f\"server delete check OK. id: {deleted_vm_id}\")"},{"line_number":79,"context_line":"                raise loopingcall.LoopingCallDone()"},{"line_number":80,"context_line":"            LOG.debug(f\"server deleting... id: {deleted_vm_id}\")"},{"line_number":81,"context_line":"            self.delete_server(deleted_vm_id)"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"        time.sleep(5)"},{"line_number":84,"context_line":"        try:"}],"source_content_type":"text/x-python","patch_set":9,"id":"29296392_5705db7c","line":81,"range":{"start_line":81,"start_character":12,"end_line":81,"end_character":45},"updated":"2026-07-23 05:29:32.000000000","message":"Thanks for the fix. I have one minor comment.\n\ndelete_server() is already called once explicitly before this polling starts. But inside _check_status(), after every 5s, delete_server() is called again.\n\nI think delete_server() call inside the polling function can be removed, as it should just check status and wait, not keep re-triggering the delete operation.","commit_id":"b23be152001ae9bcc96aba9dc81cde5be915b748"},{"author":{"_account_id":25701,"name":"Yasufumi Ogawa","email":"yasufum.o@gmail.com","username":"yasufum"},"change_message_id":"3a09f2d304731b59cd16933979b20cd80e277f1e","unresolved":true,"context_lines":[{"line_number":80,"context_line":"            LOG.debug(f\"server deleting... id: {deleted_vm_id}\")"},{"line_number":81,"context_line":"            self.delete_server(deleted_vm_id)"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"        time.sleep(5)"},{"line_number":84,"context_line":"        try:"},{"line_number":85,"context_line":"            for deleted_vm_id in deleted_vm_ids:"},{"line_number":86,"context_line":"                timer \u003d loopingcall.FixedIntervalWithTimeoutLoopingCall("}],"source_content_type":"text/x-python","patch_set":9,"id":"459fbcc3_3105ab81","line":83,"updated":"2026-08-08 08:46:04.000000000","message":"Two points here:\n\n1. This path runs for every VNFC heal, not only for the down-host case, and this unconditional time.sleep(5) to every heal even when the servers are already deleted. FixedIntervalWithTimeoutLoopingCall already paces the polling, so this  sleep looks redundant. It looks better to remove, or is there any reason it\u0027s required?\n\n2. The name is_servers_deleted() is not suitable because it looks side-effect-free predicate, but it (currently) re-sends deletes, blocks up to the timeout, raises on failure, and its True return value is never used by the caller. If the delete re-send is dropped as Shivam suggested,renaming it to something like wait_servers_deleted() and returning None would make the contract clearer.","commit_id":"b23be152001ae9bcc96aba9dc81cde5be915b748"},{"author":{"_account_id":36672,"name":"Shivam Shukla","display_name":"Shivam Shukla","email":"shivam.shukla3@india.nec.com","username":"shivam.shukla3"},"change_message_id":"fed05acd4b3afaeafda8f9f6faea5cd0d13a0f00","unresolved":true,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"        return True"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"    def delete_server(self, id):"},{"line_number":99,"context_line":"        path \u003d f\"servers/{id}\""},{"line_number":100,"context_line":"        resp, _ \u003d self.client.do_request(path, \"DELETE\","},{"line_number":101,"context_line":"            expected_status\u003d[204, 404, 409])"}],"source_content_type":"text/x-python","patch_set":9,"id":"eaf41f2d_ef7898f7","line":98,"range":{"start_line":98,"start_character":4,"end_line":98,"end_character":31},"updated":"2026-07-23 05:29:32.000000000","message":"Thank you for the fix. I have one minor comment.\n\nThe parameter name “id” is used in the “delete_server” function. While this is technically valid because id is not a reserved keyword in Python, but it is the name of a built-in function (id()). To avoid shadowing python\u0027s built-in function or issues if id() needs to be used within “delete_server” in the future, it might be better to use a more descriptive parameter name, such as “server_id”.","commit_id":"b23be152001ae9bcc96aba9dc81cde5be915b748"}],"tacker/sol_refactored/infra_drivers/openstack/openstack.py":[{"author":{"_account_id":36672,"name":"Shivam Shukla","display_name":"Shivam Shukla","email":"shivam.shukla3@india.nec.com","username":"shivam.shukla3"},"change_message_id":"fed05acd4b3afaeafda8f9f6faea5cd0d13a0f00","unresolved":true,"context_lines":[{"line_number":366,"context_line":"            nova_client \u003d nova_utils.NovaClient(vim_info)"},{"line_number":367,"context_line":"            for vnfc in inst_info.vnfcResourceInfo:"},{"line_number":368,"context_line":"                if vnfc.computeResource.resourceId in vnfc_res_ids:"},{"line_number":369,"context_line":"                    nova_client.delete_server(vnfc.id)"},{"line_number":370,"context_line":"                    heat_client.mark_unhealthy("},{"line_number":371,"context_line":"                        vnfc.metadata[\u0027stack_id\u0027], vnfc.vduId)"},{"line_number":372,"context_line":""}],"source_content_type":"text/x-python","patch_set":9,"id":"31c3b9a1_ba2ec48f","line":369,"range":{"start_line":369,"start_character":19,"end_line":369,"end_character":54},"updated":"2026-07-23 05:29:32.000000000","message":"Thank you for the fix. Please see my comment below.\n\nThere\u0027s no error handling around delete_server() inside this loop, so one failure stops everything else that hasn\u0027t run yet while anything already done before the failure is left as it is.\n\nSuppose 5 affected servers need healing, Servers 1 and 2 get deleted and marked unhealthy successfully while Server 3\u0027s delete_server() call fails (due to any Nova error), the loop stops and exit. At that point, Servers 4 and 5 are never even attempted (no delete, no mark unhealthy) and Servers 1 and 2 already had delete_server() + mark_unhealthy() done, but since the loop never reaches the later update_stack() call, that work never gets applied to the stack either.","commit_id":"b23be152001ae9bcc96aba9dc81cde5be915b748"},{"author":{"_account_id":36672,"name":"Shivam Shukla","display_name":"Shivam Shukla","email":"shivam.shukla3@india.nec.com","username":"shivam.shukla3"},"change_message_id":"fed05acd4b3afaeafda8f9f6faea5cd0d13a0f00","unresolved":true,"context_lines":[{"line_number":366,"context_line":"            nova_client \u003d nova_utils.NovaClient(vim_info)"},{"line_number":367,"context_line":"            for vnfc in inst_info.vnfcResourceInfo:"},{"line_number":368,"context_line":"                if vnfc.computeResource.resourceId in vnfc_res_ids:"},{"line_number":369,"context_line":"                    nova_client.delete_server(vnfc.id)"},{"line_number":370,"context_line":"                    heat_client.mark_unhealthy("},{"line_number":371,"context_line":"                        vnfc.metadata[\u0027stack_id\u0027], vnfc.vduId)"},{"line_number":372,"context_line":""}],"source_content_type":"text/x-python","patch_set":9,"id":"a24bb750_ee615513","line":369,"range":{"start_line":369,"start_character":19,"end_line":369,"end_character":54},"updated":"2026-07-23 05:29:32.000000000","message":"Thank you for the fix. Please see my comment below.\n\nThis call (delete_server()) is being made in a sequential loop and each server ID is waited on one at a time, the next server isn\u0027t even checked until the current one either finishes or times out.\n\nSuppose 5 affected servers needs to be confirmed deleted, and in worst case each one takes close to the full timeout (default 600s \u003d 10 min), this becomes 5 × 10 min \u003d 50 minutes total, even though openstack_vim_delete_server_timeout is meant to be a single bound (default 600s \u003d 10 min).\n\nIt think, if possible, checking all pending server IDs together in a single shared wait loop, so the whole batch is bounded by one timeout window instead of timeout × number_of_servers.","commit_id":"b23be152001ae9bcc96aba9dc81cde5be915b748"},{"author":{"_account_id":25701,"name":"Yasufumi Ogawa","email":"yasufum.o@gmail.com","username":"yasufum"},"change_message_id":"3a09f2d304731b59cd16933979b20cd80e277f1e","unresolved":true,"context_lines":[{"line_number":382,"context_line":""},{"line_number":383,"context_line":"            # update stack"},{"line_number":384,"context_line":"            try:"},{"line_number":385,"context_line":"                nova_client.is_servers_deleted(vnfc_res_ids)"},{"line_number":386,"context_line":"                heat_client.update_stack(stack_name, fields)"},{"line_number":387,"context_line":"            except sol_ex.StackOperationFailed as ex:"},{"line_number":388,"context_line":"                vdu_ids \u003d self._get_vdu_id_from_grant_req(grant_req, inst)"}],"source_content_type":"text/x-python","patch_set":9,"id":"df6b723b_8feeed5d","line":385,"updated":"2026-08-08 08:46:04.000000000","message":"is_servers_deleted() raises sol_ex.StackOperationFailed on timeout, and this call sits inside the try block whose except handler runs _update_stack_retry() — i.e. a server-deletion timeout is routed into the availability-zone reselection logic. Today this \"works\" only by accident: _check_and_get_failed_zone() fails to match the detail string (\"get server status failed\") and re-raises. But semantically a deletion timeout has nothing to do with AZ reselection.\n\nI\u0027d suggest either moving this call outside the try block, or raising a dedicated exception type that the update_stack handler does not catch.","commit_id":"b23be152001ae9bcc96aba9dc81cde5be915b748"}]}