diff options
| author | Matt Riedemann <mriedem.os@gmail.com> | 2019-03-26 09:55:23 -0400 |
|---|---|---|
| committer | Matt Riedemann <mriedem.os@gmail.com> | 2019-03-29 09:38:45 -0400 |
| commit | 4d0aab16ecac5128a20ab9229d444bc49a9c722b (patch) | |
| tree | bc5e4eb08adfe1917afb86e550d94c1a164d7825 | |
| parent | 03a6d26691c1f182224d59190b79f48df278099e (diff) | |
| download | nova-4d0aab16ecac5128a20ab9229d444bc49a9c722b.tar.gz | |
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
| -rw-r--r-- | api-ref/source/servers-actions.inc | 18 | ||||
| -rw-r--r-- | 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 dcb60d4a3d..73335a5951 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 859b0d769f..de1e3b84d6 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) ========================================= |