)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4c337fdeef122c5fe1089b89eac8b4dba6d059df","unresolved":false,"context_lines":[{"line_number":24,"context_line":"the affected compute service and also blocks attempts to migrate"},{"line_number":25,"context_line":"instances hosted by it."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Related-Bug: #1817833"},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Change-Id: Iab5baaa511fccb0be9d4df03dbc7a80320b7a0fc"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3fa7e38b_245d197c","line":27,"updated":"2019-12-18 14:10:58.000000000","message":"Note that test_evacuate_then_delete_compute_service was written for this bug involving an evacuated-from compute service being deleted. It\u0027s probably fine to say this is related, it\u0027s just a different scenario to get to the same kind of issue I think (without evacuate).","commit_id":"30d28d88b2569517fe27725e5379922f963b5bb6"}],"nova/tests/functional/wsgi/test_services.py":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f085194e0fbaef04bc660c326ca5da8a10b346e2","unresolved":false,"context_lines":[{"line_number":275,"context_line":"        \"\"\"Tests a scenario where the admin deletes a service and a failure"},{"line_number":276,"context_line":"        occurs when deleting the resource provider in placement."},{"line_number":277,"context_line":"        \"\"\""},{"line_number":278,"context_line":"        mock_delete_rp.side_effect \u003d exception.ResourceProviderDeletionFailed("},{"line_number":279,"context_line":"            uuid\u003d\u0027fake-uuid\u0027)"},{"line_number":280,"context_line":"        compute \u003d self._start_compute(\u0027host1\u0027)"},{"line_number":281,"context_line":"        service \u003d self.admin_api.get_services("}],"source_content_type":"text/x-python","patch_set":1,"id":"3fa7e38b_64547123","line":278,"updated":"2019-12-18 14:24:00.000000000","message":"While this is a different error that causes the provider to not be deleted, test_evacuate_then_delete_compute_service is covering essentially the same scenario.\n\nWith https://review.opendev.org/#/c/678100/3/nova/compute/manager.py I thought you wanted to cover the case that the compute manager\u0027s update_available_resource method destroys the compute node and tries to delete the provider which fails because placement is down, which then orphans the provider and subsequent restarts fails. That\u0027s a bit more involved test but still doable (see PeriodicNodeRecreateTestCase).\n\nIn your downstream recreate, are they ironic nodes or libvirt nodes? I suspect ironic because (1) tripleo and (2) that\u0027s about the only case that the update_available_resource code finds orphaned computes and deletes them. I\u0027d think you could borrow from NodeRebalanceDeletedComputeNodeRaceTestCase where the driver reports a couple of nodes, then it doesn\u0027t report one of the nodes so we delete it and that\u0027s where you\u0027d inject the provider deletion as though placement were down.\n\nThe thing I don\u0027t know yet is what the answer is in that case - block deletion of the compute node resource I guess so we don\u0027t orphan the provider in placement which is the direction we\u0027ve taken in the API as well with I70e06c607045a1c0842f13069e51fef438012a9c and Ic634a5957e38beca693304c605d1b6fd36eacc77.","commit_id":"30d28d88b2569517fe27725e5379922f963b5bb6"}]}