Open Stack

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.

Today.... there is a giant hodgepodge - see:

https://github.com/openstack/tempest-lib/blob/master/tempest_lib/common/rest_client.py#L412-L424

https://github.com/openstack/tempest-lib/blob/master/tempest_lib/common/rest_client.py#L460-L492

Especially blocks like this:

                        if 'cloudServersFault' in resp_body:
                            message =
resp_body['cloudServersFault']['message']
                        elif 'computeFault' in resp_body:
                            message = resp_body['computeFault']['message']
                        elif 'error' in resp_body:
                            message = resp_body['error']['message']
                        elif 'message' in resp_body:
                            message = resp_body['message']

Standardization here from the API WG would be really great.

	-Sean

On 01/29/2015 09:11 AM, Roman Podoliaka wrote:
> Hi Anne,
> 
> I think Eugeniya refers to a problem, that we can't really distinguish
> between two different  badRequest (400) errors (e.g. wrong security
> group name vs wrong key pair name when starting an instance), unless
> we parse the error description, which might be error prone.
> 
> Thanks,
> Roman
> 
> On Thu, Jan 29, 2015 at 6:46 PM, Anne Gentle
> <annegentle at justwriteclick.com> wrote:
>>
>>
>> On Thu, Jan 29, 2015 at 10:33 AM, Eugeniya Kudryashova
>> <ekudryashova at mirantis.com> wrote:
>>>
>>> Hi, all
>>>
>>>
>>> Openstack APIs interact with each other and external systems partially by
>>> passing of HTTP errors. The only valuable difference between types of
>>> exceptions is HTTP-codes, but current codes are generalized, so external
>>> system can’t distinguish what actually happened.
>>>
>>>
>>> As an example two different failures below differs only by error message:
>>>
>>>
>>> request:
>>>
>>> POST /v2/790f5693e97a40d38c4d5bfdc45acb09/servers HTTP/1.1
>>>
>>> Host: 192.168.122.195:8774
>>>
>>> X-Auth-Project-Id: demo
>>>
>>> Accept-Encoding: gzip, deflate, compress
>>>
>>> Content-Length: 189
>>>
>>> Accept: application/json
>>>
>>> User-Agent: python-novaclient
>>>
>>> X-Auth-Token: 2cfeb9283d784cfba694f3122ef413bf
>>>
>>> Content-Type: application/json
>>>
>>>
>>> {"server": {"name": "demo", "imageRef":
>>> "171c9d7d-3912-4547-b2a5-ea157eb08622", "key_name": "test", "flavorRef":
>>> "42", "max_count": 1, "min_count": 1, "security_groups": [{"name": "bar"}]}}
>>>
>>> response:
>>>
>>>     HTTP/1.1 400 Bad Request
>>>
>>> Content-Length: 118
>>>
>>> Content-Type: application/json; charset=UTF-8
>>>
>>> X-Compute-Request-Id: req-a995e1fc-7ea4-4305-a7ae-c569169936c0
>>>
>>> Date: Fri, 23 Jan 2015 10:43:33 GMT
>>>
>>>
>>> {"badRequest": {"message": "Security group bar not found for project
>>> 790f5693e97a40d38c4d5bfdc45acb09.", "code": 400}}
>>>
>>>
>>> and
>>>
>>>
>>> request:
>>>
>>> POST /v2/790f5693e97a40d38c4d5bfdc45acb09/servers HTTP/1.1
>>>
>>> Host: 192.168.122.195:8774
>>>
>>> X-Auth-Project-Id: demo
>>>
>>> Accept-Encoding: gzip, deflate, compress
>>>
>>> Content-Length: 192
>>>
>>> Accept: application/json
>>>
>>> User-Agent: python-novaclient
>>>
>>> X-Auth-Token: 24c0d30ff76c42e0ae160fa93db8cf71
>>>
>>> Content-Type: application/json
>>>
>>>
>>> {"server": {"name": "demo", "imageRef":
>>> "171c9d7d-3912-4547-b2a5-ea157eb08622", "key_name": "foo", "flavorRef":
>>> "42", "max_count": 1, "min_count": 1, "security_groups": [{"name":
>>> "default"}]}}
>>>
>>> response:
>>>
>>> HTTP/1.1 400 Bad Request
>>>
>>> Content-Length: 70
>>>
>>> Content-Type: application/json; charset=UTF-8
>>>
>>> X-Compute-Request-Id: req-87604089-7071-40a7-a34b-7bc56d0551f5
>>>
>>> Date: Fri, 23 Jan 2015 10:39:43 GMT
>>>
>>>
>>> {"badRequest": {"message": "Invalid key_name provided.", "code": 400}}
>>>
>>>
>>> The former specifies an incorrect security group name, and the latter an
>>> incorrect keypair name. And the problem is, that just looking at the
>>> response body and HTTP response code an external system can’t understand
>>> what exactly went wrong. And parsing of error messages here is not the way
>>> we’d like to solve this problem.
>>
>>
>> For the Compute API v 2 we have the shortened Error Code in the
>> documentation at
>> http://developer.openstack.org/api-ref-compute-v2.html#compute_server-addresses
>>
>> such as:
>>
>> Error response codes
>> computeFault (400, 500, …), serviceUnavailable (503), badRequest (400),
>> unauthorized (401), forbidden (403), badMethod (405), overLimit (413),
>> itemNotFound (404), buildInProgress (409)
>>
>> Thanks to a recent update (well, last fall) to our build tool for docs.
>>
>> What we don't have is a table in the docs saying "computeFault has this
>> longer Description" -- is that what you are asking for, for all OpenStack
>> APIs?
>>
>> Tell me more.
>>
>> Anne
>>
>>
>>>
>>>
>>> Another example for solving this problem is AWS EC2 exception codes [1]
>>>
>>>
>>> So if we have some service based on Openstack projects it would be useful
>>> to have some concrete error codes(textual or numeric), which could allow to
>>> define what actually goes wrong and later correctly process obtained
>>> exception. These codes should be predefined for each exception, have
>>> documented structure and allow to parse exception correctly in each step of
>>> exception handling.
>>>
>>>
>>> So I’d like to discuss implementing such codes and its usage in openstack
>>> projects.
>>>
>>>
>>> [1] -
>>> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>
>>
>>
>> --
>> Anne Gentle
>> annegentle at justwriteclick.com
>>
>> __________________________________________________________________________
>> 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
>>
> 
> __________________________________________________________________________
> 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
> 


-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150129/5ec0125b/attachment.pgp>