Browse Source

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
changes/41/647741/3
Matt Riedemann 5 months ago
parent
commit
4d0aab16ec
2 changed files with 16 additions and 3 deletions
  1. 15
    3
      api-ref/source/servers-actions.inc
  2. 1
    0
      api-ref/source/servers-admin-action.inc

+ 15
- 3
api-ref/source/servers-actions.inc View File

@@ -162,7 +162,7 @@ Specify the ``confirmResize`` action in the request body.
162 162
 After you make this request, you typically must keep polling the server
163 163
 status to determine whether the request succeeded. A successfully
164 164
 confirming resize operation shows a status of ``ACTIVE`` or ``SHUTOFF``
165
-and a migration_status of ``confirmed``. You can also see the resized
165
+and a migration status of ``confirmed``. You can also see the resized
166 166
 server in the compute node that OpenStack Compute manages.
167 167
 
168 168
 **Preconditions**
@@ -175,9 +175,20 @@ to confirm the server.
175 175
 
176 176
 **Troubleshooting**
177 177
 
178
-If the server status remains ``RESIZED``, the request failed. Ensure you
178
+If the server status remains ``VERIFY_RESIZE``, the request failed. Ensure you
179 179
 meet the preconditions and run the request again. If the request fails
180
-again, investigate the compute back end or ask your cloud provider.
180
+again, the server status should be ``ERROR`` and a migration status of
181
+``error``. Investigate the compute back end or ask your cloud provider.
182
+There are some options for trying to correct the server status:
183
+
184
+* If the server is running and networking works, a user with proper
185
+  authority could reset the status of the server to ``active`` using the
186
+  :ref:`os-resetState` API.
187
+* If the server is not running, you can try hard rebooting the server using
188
+  the :ref:`reboot` API.
189
+
190
+Note that the cloud provider may still need to cleanup any orphaned resources
191
+on the source hypervisor.
181 192
 
182 193
 Normal response codes: 204
183 194
 
@@ -451,6 +462,7 @@ Response
451 462
 
452 463
 If successful, this method does not return content in the response body.
453 464
 
465
+.. _reboot:
454 466
 
455 467
 Reboot Server (reboot Action)
456 468
 =============================

+ 1
- 0
api-ref/source/servers-admin-action.inc View File

@@ -211,6 +211,7 @@ Response
211 211
 
212 212
 If successful, this method does not return content in the response body.
213 213
 
214
+.. _os-resetState:
214 215
 
215 216
 Reset Server State (os-resetState Action)
216 217
 =========================================

Loading…
Cancel
Save