)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"72ecd3940d703f060d0731434f31da776d57beb9","unresolved":true,"context_lines":[{"line_number":14,"context_line":"clears task_state) and finish_evacuation (which updates instance.host)."},{"line_number":15,"context_line":"When the periodic fires in this window, the evacuating instance\u0027s"},{"line_number":16,"context_line":"pinned CPUs are not accounted for, and the next rebuild_claim assigns"},{"line_number":17,"context_line":"the same pCPUs to another instance."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Related-Bug: #2162835"},{"line_number":20,"context_line":"Assisted-By: Claude-Code opus 4.6"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"551a64a1_6afaabe2","line":17,"updated":"2026-08-19 14:01:37.000000000","message":"just by looking at the baseline code it seems that the intention is that the migration context is still holding the allocation between _update_instance_after_spawn and finish_evacuation. So the periodic should see the allocation via the migration context.\n\nhaving and empty task state but not having the instance.host set is alone a big gap regardless of the periodic as it would allow another action to be executed on this instance and that will see no host.","commit_id":"73893494d2d2b4809d6b7faf00cc126d80386de6"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"72ecd3940d703f060d0731434f31da776d57beb9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a568e7a9_b6b544de","updated":"2026-08-19 14:01:37.000000000","message":"It seems a valid bug reproduction. Thanks. I suggested making the injection of the periodics run cleaner.","commit_id":"73893494d2d2b4809d6b7faf00cc126d80386de6"}],"nova/tests/functional/regressions/test_bug_2162835.py":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"72ecd3940d703f060d0731434f31da776d57beb9","unresolved":true,"context_lines":[{"line_number":111,"context_line":"                    self.host_mappings[\u0027host2\u0027].cell_mapping,"},{"line_number":112,"context_line":"                ) as cctxt:"},{"line_number":113,"context_line":"                    self.computes[\u0027host2\u0027].manager.\\"},{"line_number":114,"context_line":"                        update_available_resource(cctxt)"},{"line_number":115,"context_line":"            return original_finish(instance, node, migration)"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"        with mock.patch.object(rt, \u0027finish_evacuation\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"305d819f_6252e670","line":114,"updated":"2026-08-19 14:01:37.000000000","message":"This is a bit invasive as periodics are never called from that specific place of the code so the state of the locks grabbed by the process might not be realistic to a periodic starting to run.\n\nWe can stop the mock_finish() with a threading.Event. And then trigger the periodic from the test case, and then set the event to allow the mock_finish to continue. We even have some helpers to trigger the periodic from the test code.`self._run_periodics()`. This will be a little cleaner. \n\n(you probably need two events one to signal that finish is entered and therefore periodics can start, and another that signals from the test to the finish to continue after the periodics)\n\n(also you need to split the _evacuate_server call to two 1] triggering the action 2] periodic stuff 3] waiting for the evacution to finish. And for that to work you need to switch this test to be a \"proper\" parallel test via CAST_AS_CALL disabled)","commit_id":"73893494d2d2b4809d6b7faf00cc126d80386de6"}]}