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
This commit is contained in:
parent
03a6d26691
commit
4d0aab16ec
|
@ -162,7 +162,7 @@ Specify the ``confirmResize`` action in the request body.
|
||||||
After you make this request, you typically must keep polling the server
|
After you make this request, you typically must keep polling the server
|
||||||
status to determine whether the request succeeded. A successfully
|
status to determine whether the request succeeded. A successfully
|
||||||
confirming resize operation shows a status of ``ACTIVE`` or ``SHUTOFF``
|
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.
|
server in the compute node that OpenStack Compute manages.
|
||||||
|
|
||||||
**Preconditions**
|
**Preconditions**
|
||||||
|
@ -175,9 +175,20 @@ to confirm the server.
|
||||||
|
|
||||||
**Troubleshooting**
|
**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
|
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
|
Normal response codes: 204
|
||||||
|
|
||||||
|
@ -451,6 +462,7 @@ Response
|
||||||
|
|
||||||
If successful, this method does not return content in the response body.
|
If successful, this method does not return content in the response body.
|
||||||
|
|
||||||
|
.. _reboot:
|
||||||
|
|
||||||
Reboot Server (reboot Action)
|
Reboot Server (reboot Action)
|
||||||
=============================
|
=============================
|
||||||
|
|
|
@ -211,6 +211,7 @@ Response
|
||||||
|
|
||||||
If successful, this method does not return content in the response body.
|
If successful, this method does not return content in the response body.
|
||||||
|
|
||||||
|
.. _os-resetState:
|
||||||
|
|
||||||
Reset Server State (os-resetState Action)
|
Reset Server State (os-resetState Action)
|
||||||
=========================================
|
=========================================
|
||||||
|
|
Loading…
Reference in New Issue