Open Stack

If you're going to make up your own extensions[1] to HTTP, why don't you use ones that are already used?

http://support.microsoft.com/kb/943891



[1] ok, what's proposed isn't technically an "extension", it's response body context for the response code. But response bodies are hard to modify when you're dealing with APIs that aren't control-plane APIs.

--John



> On Jan 29, 2015, at 9:41 AM, Sean Dague <sean at dague.net> 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.
> 
> 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
> 
> __________________________________________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150129/a86064b8/attachment.pgp>