[openstack-dev] [api][nova] Openstack HTTP error codes

Brant Knudson blk at acm.org
Tue Feb 3 01:45:34 UTC 2015


On Mon, Feb 2, 2015 at 4:35 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 01/29/2015 12:41 PM, Sean Dague wrote:
>
>> Correct. This actually came up at the Nova mid cycle in a side
>> conversation with Ironic and Neutron folks.
>>
>> HTTP error codes are not sufficiently granular to describe what happens
>> when a REST service goes wrong, especially if it goes wrong in a way
>> that would let the client do something other than blindly try the same
>> request, or fail.
>>
>> Having a standard json error payload would be really nice.
>>
>> {
>>       fault: ComputeFeatureUnsupportedOnInstanceType,
>>       messsage: "This compute feature is not supported on this kind of
>> instance type. If you need this feature please use a different instance
>> type. See your cloud provider for options."
>> }
>>
>> That would let us surface more specific errors.
>>
> <snip>
>
>>
>> Standardization here from the API WG would be really great.
>>
>
> What about having a separate HTTP header that indicates the "OpenStack
> Error Code", along with a generated URI for finding more information about
> the error?
>
> Something like:
>
> X-OpenStack-Error-Code: 1234
> X-OpenStack-Error-Help-URI: http://errors.openstack.org/1234
>
> That way is completely backwards compatible (since we wouldn't be changing
> response payloads) and we could handle i18n entirely via the HTTP help
> service running on errors.openstack.org.
>
>
Some of the suggested formats for an error document allow for multiple
errors, which would be useful in an input validation case since there may
be multiple fields that are incorrect (missing or wrong format).

One option to keep backwards compatibility is have both formats in the same
object. Keystone currently returns an error document like:

$ curl -X DELETE -H "X-auth-token: $TOKEN"
http://localhost:5000/v3/groups/lkdsajlkdsa/users/lkajfdskdsajf
{"error": {"message": "Could not find user: lkajfdskdsajf", "code": 404,
"title": "Not Found"}}

So an enhanced error document could have:

$ curl -X DELETE -H "X-auth-token: $TOKEN"
http://localhost:5000/v3/groups/lkdsajlkdsa/users/lkajfdskdsajf
{"error": {"message": "Could not find user: lkajfdskdsajf", "code": 404,
"title": "Not Found"},
 "errors": [ { "message": "Could not find group: lkdsajlkdsa", "id":
"groupNotFound" },
                 { "message": "Could not find user: lkajfdskdsajf", "id":
"userNotFound" } ]
}

Then when identity API 4 comes out we drop the deprecated "error" field.

- Brant



> Best,
> -jay
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150202/3a30babb/attachment.html>


More information about the OpenStack-dev mailing list