Files
5ee95b324085bbbb7fbce3b4deb236a3e916a622
nova /api-guide /source /faults.rst

145 lines
4.8 KiB
ReStructuredText
Raw Normal View History

Faults
======
This doc explains how to understand what has happened to your API request.
However, that is often not the end of the story. That generally only means the
request to start the operation has been accepted. It does not mean the action
This is returned in a response header.
Here is an example response header:
--------------
referencing the requested action by request id.
http://developer.openstack.org/api-ref-compute-v2.1.html#os-instance-actions-v2.1
----
This allows an administrator to track the API request processing as it
transitions between all the different nova services.
---------------
focused information, such as a stack trace.
-------------
This is an administrator focused API, that works best when treated as
structured logging.
==================
API status code. The system also returns additional
information about the fault in the body of the response.
.. code::
{
"code": 404,
"message":"Aggregate agg_h1 could not be found."
}
The error ``code`` is returned in the body of the response for convenience.
The ``message`` section returns a human-readable message that is appropriate
for display to the end user. The ``details`` section is optional and may
down an error. The ``details`` section might or might not be appropriate for
depending on the type of error. The following link contains a list of possible
http://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-response-codes
Asynchronous faults
server is executing an action.
operations, like resize, its possible that the operations fails but
operation. In both of these cases, you should be able to find out more from
the Server Actions API described above.
offending server. Note that these asynchronous faults follow the same format
as the synchronous ones. The fault contains an error code, a human readable
message, and optional details about the error. Additionally, asynchronous
faults may also contain a ``created`` timestamp that specifies when the fault
**Example:Server in error state: JSON response**
.. code::
{
"server": {
"id": "52415800-8b69-11e0-9b19-734f0000ffff",
"tenant_id": "1234",
"user_id": "5678",
"name": "sample-server",
"created": "2010年08月10日T12:00:00Z",
"hostId": "e4d909c290d0fb1ca068ffafff22cbd0",
"status": "ERROR",
"progress": 66,
"image" : {
"id": "52415800-8b69-11e0-9b19-734f6f007777"
},
"flavor" : {
"id": "52415800-8b69-11e0-9b19-734f216543fd"
},
"fault" : {
"details": [snip]
"links": [
{
"rel": "self",
"href": "http://servers.api.openstack.org/v2/1234/servers/52415800-8b69-11e0-9b19-734f000004d2"
},
{
"rel": "bookmark",
"href": "http://servers.api.openstack.org/1234/servers/52415800-8b69-11e0-9b19-734f000004d2"
}
]
}
}