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 <s...@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 >> <annegen...@justwriteclick.com> wrote: >>> >>> >>> On Thu, Jan 29, 2015 at 10:33 AM, Eugeniya Kudryashova >>> <ekudryash...@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-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> >>> -- >>> Anne Gentle >>> annegen...@justwriteclick.com >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
