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:
Matt Riedemann 2019-03-26 09:55:23 -04:00
parent 03a6d26691
commit 4d0aab16ec
2 changed files with 16 additions and 3 deletions

View File

@ -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)
============================= =============================

View File

@ -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)
========================================= =========================================