From 4d0aab16ecac5128a20ab9229d444bc49a9c722b Mon Sep 17 00:00:00 2001 From: Matt Riedemann Date: Tue, 26 Mar 2019 09:55:23 -0400 Subject: [PATCH] api-ref: add more details to confirmResize troubleshooting This does a few things: 1. Fixes the "migration_status" wording since that does not exist and could be confused as a field on the server resource which it is not, it is referring to the migration resource status. 2. Fixes the RESIZED status mention since that is not a real server status, it probably meant VERIFY_RESIZE (RESIZED is the name of the nova.compute.vm_states variable used in the code to set the VERIFY_RESIZE status in the API). 3. Adds words about options to correct the server status from ERROR after confirmResize fails, the most obvious being an admin resetting the server status to ACTIVE or the user hard rebooting the server. Change-Id: I7de257ad78031d137616d724bee3fa1cbf40d6fa Related-Bug: #1821594 --- api-ref/source/servers-actions.inc | 18 +++++++++++++++--- api-ref/source/servers-admin-action.inc | 1 + 2 files changed, 16 insertions(+), 3 deletions(-) diff --git a/api-ref/source/servers-actions.inc b/api-ref/source/servers-actions.inc index dcb60d4a3d2b..73335a5951c3 100644 --- a/api-ref/source/servers-actions.inc +++ b/api-ref/source/servers-actions.inc @@ -162,7 +162,7 @@ Specify the ``confirmResize`` action in the request body. After you make this request, you typically must keep polling the server status to determine whether the request succeeded. A successfully confirming resize operation shows a status of ``ACTIVE`` or ``SHUTOFF`` -and a migration_status of ``confirmed``. You can also see the resized +and a migration status of ``confirmed``. You can also see the resized server in the compute node that OpenStack Compute manages. **Preconditions** @@ -175,9 +175,20 @@ to confirm the server. **Troubleshooting** -If the server status remains ``RESIZED``, the request failed. Ensure you +If the server status remains ``VERIFY_RESIZE``, the request failed. Ensure you meet the preconditions and run the request again. If the request fails -again, investigate the compute back end or ask your cloud provider. +again, the server status should be ``ERROR`` and a migration status of +``error``. Investigate the compute back end or ask your cloud provider. +There are some options for trying to correct the server status: + +* If the server is running and networking works, a user with proper + authority could reset the status of the server to ``active`` using the + :ref:`os-resetState` API. +* If the server is not running, you can try hard rebooting the server using + the :ref:`reboot` API. + +Note that the cloud provider may still need to cleanup any orphaned resources +on the source hypervisor. Normal response codes: 204 @@ -451,6 +462,7 @@ Response If successful, this method does not return content in the response body. +.. _reboot: Reboot Server (reboot Action) ============================= diff --git a/api-ref/source/servers-admin-action.inc b/api-ref/source/servers-admin-action.inc index 859b0d769f8a..de1e3b84d60a 100644 --- a/api-ref/source/servers-admin-action.inc +++ b/api-ref/source/servers-admin-action.inc @@ -211,6 +211,7 @@ Response If successful, this method does not return content in the response body. +.. _os-resetState: Reset Server State (os-resetState Action) =========================================