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

2015-03-31 Thread Everett Toews
Top posting to continue the discussion in another thread.

[openstack-dev] [all] [api] Erring is Caring
http://lists.openstack.org/pipermail/openstack-dev/2015-March/060314.html

Everett


On Feb 4, 2015, at 10:29 AM, Duncan Thomas 
duncan.tho...@gmail.commailto:duncan.tho...@gmail.com wrote:

Ideally there would need to be a way to replicate 
errors.openstack.orghttp://errors.openstack.org/ and switch the url, for 
none-internet connected deployments, but TBH sites with that sort of 
requirement are used to weird breakages, so not a huge issue of it can't easily 
be done

On 3 February 2015 at 00:35, Jay Pipes 
jaypi...@gmail.commailto:jaypi...@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.orghttp://errors.openstack.org/.

Best,
-jay


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto: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


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

2015-02-13 Thread Jay Pipes

On 02/12/2015 09:59 PM, Robert Collins wrote:

On 5 February 2015 at 13:20, Rochelle Grober rochelle.gro...@huawei.com wrote:

Duncan Thomas [mailto:duncan.tho...@gmail.com] on Wednesday, February 04,
2015 8:34 AM wrote:



The downside of numbers rather than camel-case text is that they are less
likely to stick in the memory of regular users. Not a huge think, but a
reduction in usability, I think. On the other hand they might lead to less
guessing about the error with insufficient info, I suppose.

To make the global registry easier, we can just use a per-service prefix,
and then keep the error catalogue in the service code repo, pulling them
into some sort of release periodically



[Rockyg]  In discussions at the summit about assigning error codes, we
determined it would be pretty straightforward to build a tool that could be
called when a new code was needed and it would both assign an unused code
and insert the error summary for the code in the DB it would keep to ensure
uniqueness.  If you didn’t provide a summary, it wouldn’t spit out an error
code;-)  Simple little tool that could be in oslo, or some cross-project
code location.


Apropos of logging, has https://tools.ietf.org/html/rfc5424 been
considered? Combined with https://tools.ietf.org/html/rfc5426 we'd
have a standards based (and thus already supported by logging and
analysis tools) framework. aka, we seem to be on the verge of
inventing a thing thats already been invented.


In what way are either of the above RFCs guidance to our conversation 
about how to properly codify error codes in our HTTP APIs?


Best,
-jay

__
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


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

2015-02-13 Thread Robert Collins
Argh. Wrong thread. Sorry. I was aiming for one about logging :(
On 14 Feb 2015 01:48, Jay Pipes jaypi...@gmail.com wrote:

 On 02/12/2015 09:59 PM, Robert Collins wrote:

 On 5 February 2015 at 13:20, Rochelle Grober rochelle.gro...@huawei.com
 wrote:

 Duncan Thomas [mailto:duncan.tho...@gmail.com] on Wednesday, February
 04,
 2015 8:34 AM wrote:



 The downside of numbers rather than camel-case text is that they are less
 likely to stick in the memory of regular users. Not a huge think, but a
 reduction in usability, I think. On the other hand they might lead to
 less
 guessing about the error with insufficient info, I suppose.

 To make the global registry easier, we can just use a per-service prefix,
 and then keep the error catalogue in the service code repo, pulling them
 into some sort of release periodically



 [Rockyg]  In discussions at the summit about assigning error codes, we
 determined it would be pretty straightforward to build a tool that could
 be
 called when a new code was needed and it would both assign an unused code
 and insert the error summary for the code in the DB it would keep to
 ensure
 uniqueness.  If you didn’t provide a summary, it wouldn’t spit out an
 error
 code;-)  Simple little tool that could be in oslo, or some cross-project
 code location.


 Apropos of logging, has https://tools.ietf.org/html/rfc5424 been
 considered? Combined with https://tools.ietf.org/html/rfc5426 we'd
 have a standards based (and thus already supported by logging and
 analysis tools) framework. aka, we seem to be on the verge of
 inventing a thing thats already been invented.


 In what way are either of the above RFCs guidance to our conversation
 about how to properly codify error codes in our HTTP APIs?

 Best,
 -jay

 __
 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


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

2015-02-12 Thread Robert Collins
On 5 February 2015 at 13:20, Rochelle Grober rochelle.gro...@huawei.com wrote:
 Duncan Thomas [mailto:duncan.tho...@gmail.com] on Wednesday, February 04,
 2015 8:34 AM wrote:



 The downside of numbers rather than camel-case text is that they are less
 likely to stick in the memory of regular users. Not a huge think, but a
 reduction in usability, I think. On the other hand they might lead to less
 guessing about the error with insufficient info, I suppose.

 To make the global registry easier, we can just use a per-service prefix,
 and then keep the error catalogue in the service code repo, pulling them
 into some sort of release periodically



 [Rockyg]  In discussions at the summit about assigning error codes, we
 determined it would be pretty straightforward to build a tool that could be
 called when a new code was needed and it would both assign an unused code
 and insert the error summary for the code in the DB it would keep to ensure
 uniqueness.  If you didn’t provide a summary, it wouldn’t spit out an error
 code;-)  Simple little tool that could be in oslo, or some cross-project
 code location.

Apropos of logging, has https://tools.ietf.org/html/rfc5424 been
considered? Combined with https://tools.ietf.org/html/rfc5426 we'd
have a standards based (and thus already supported by logging and
analysis tools) framework. aka, we seem to be on the verge of
inventing a thing thats already been invented.

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

__
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


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

2015-02-04 Thread Duncan Thomas
The downside of numbers rather than camel-case text is that they are less
likely to stick in the memory of regular users. Not a huge think, but a
reduction in usability, I think. On the other hand they might lead to less
guessing about the error with insufficient info, I suppose.

To make the global registry easier, we can just use a per-service prefix,
and then keep the error catalogue in the service code repo, pulling them
into some sort of release periodically

On 3 February 2015 at 03:24, Sean Dague s...@dague.net wrote:

 On 02/02/2015 05:35 PM, Jay Pipes 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.

 That could definitely be implemented in the short term, but if we're
 talking about API WG long term evolution, I'm not sure why a standard
 error payload body wouldn't be better.

 The if we are going to having global codes that are just numbers, we'll
 also need a global naming registry. Which isn't a bad thing, just
 someone will need to allocate the numbers in a separate global repo
 across all projects.

 -Sean

 --
 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




-- 
Duncan Thomas
__
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


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

2015-02-04 Thread Duncan Thomas
Ideally there would need to be a way to replicate errors.openstack.org and
switch the url, for none-internet connected deployments, but TBH sites with
that sort of requirement are used to weird breakages, so not a huge issue
of it can't easily be done

On 3 February 2015 at 00:35, Jay Pipes jaypi...@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.

 Best,
 -jay


 __
 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




-- 
Duncan Thomas
__
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


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

2015-02-04 Thread Rochelle Grober
Duncan Thomas [mailto:duncan.tho...@gmail.com] on Wednesday, February 04, 2015 
8:34 AM wrote:

The downside of numbers rather than camel-case text is that they are less 
likely to stick in the memory of regular users. Not a huge think, but a 
reduction in usability, I think. On the other hand they might lead to less 
guessing about the error with insufficient info, I suppose.
To make the global registry easier, we can just use a per-service prefix, and 
then keep the error catalogue in the service code repo, pulling them into some 
sort of release periodically

[Rockyg]  In discussions at the summit about assigning error codes, we 
determined it would be pretty straightforward to build a tool that could be 
called when a new code was needed and it would both assign an unused code and 
insert the error summary for the code in the DB it would keep to ensure 
uniqueness.  If you didn’t provide a summary, it wouldn’t spit out an error 
code;-)  Simple little tool that could be in oslo, or some cross-project code 
location.

--Rocky

On 3 February 2015 at 03:24, Sean Dague s...@dague.netmailto:s...@dague.net 
wrote:
On 02/02/2015 05:35 PM, Jay Pipes 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.orghttp://errors.openstack.org.
That could definitely be implemented in the short term, but if we're
talking about API WG long term evolution, I'm not sure why a standard
error payload body wouldn't be better.

The if we are going to having global codes that are just numbers, we'll
also need a global naming registry. Which isn't a bad thing, just
someone will need to allocate the numbers in a separate global repo
across all projects.

-Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Duncan Thomas
__
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


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

2015-02-03 Thread Robert Collins
On 30 January 2015 at 09:04, John Dickinson m...@not.mn wrote:
 I think there are two points. First, the original requirement (in the first 
 email on this thread) is not what's wanted:

 ...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.

 So adding a response body to parse doesn't solve the problem. The request as 
 I read it is to have a set of well-defined error codes to know what happens.

 Second, my response is a little tongue-in-cheek, because I think the IIS 
 response codes are a perfect example of extending a common, well-known 
 protocol with custom extensions that breaks existing clients. I would hate to 
 see us do that.

 So if we can't subtly break http, and we can't have error response documents, 
 then we're left with custom error codes in the particular response-code 
 class. eg 461 SecurityGroupNotFound or 462 InvalidKeyName (from the original 
 examples)

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-6

I'm quite certain IIS isn't putting 401.1 in the status code - it
would fail on every client everywhere - I think they may include an
extra header though.

I don't understand your objection to a body: AIUI the original
complaint it was that parsing a free-form text field was bad.
Structured data (e.g. JSON) is a whole different kettle of fish, as it
could have a freeform field but also a machine understood field (be
that numeric, an enumeration or whatever).

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

__
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


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

2015-02-03 Thread Jay Pipes

On 02/02/2015 09:07 PM, Everett Toews wrote:

On Feb 2, 2015, at 7:24 PM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:


On 02/02/2015 05:35 PM, Jay Pipes 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
http://errors.openstack.org.


That could definitely be implemented in the short term, but if we're
talking about API WG long term evolution, I'm not sure why a standard
error payload body wouldn't be better.


Agreed. And using the “X-“ prefix in headers has been deprecated for
over 2 years now [1]. I don’t think we should be using it for new things.

Everett

[1] https://tools.ietf.org/html/rfc6648


Ha! Good to know about the X- stuff :) Duly noted!

-jay

__
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


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

2015-02-03 Thread Kevin Benton
So do we just use whatever name we want instead? Can we use 'referrer'? ;-)

On Tue, Feb 3, 2015 at 5:43 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 02/02/2015 09:07 PM, Everett Toews wrote:

 On Feb 2, 2015, at 7:24 PM, Sean Dague s...@dague.net
 mailto:s...@dague.net wrote:

  On 02/02/2015 05:35 PM, Jay Pipes 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
 http://errors.openstack.org.


 That could definitely be implemented in the short term, but if we're
 talking about API WG long term evolution, I'm not sure why a standard
 error payload body wouldn't be better.


 Agreed. And using the “X-“ prefix in headers has been deprecated for
 over 2 years now [1]. I don’t think we should be using it for new things.

 Everett

 [1] https://tools.ietf.org/html/rfc6648


 Ha! Good to know about the X- stuff :) Duly noted!


 -jay

 __
 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




-- 
Kevin Benton
__
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


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

2015-02-03 Thread Jay Pipes

On 02/03/2015 06:54 PM, Kevin Benton wrote:

So do we just use whatever name we want instead? Can we use 'referrer'? ;-)


:) How about Content-Length?

-jay


On Tue, Feb 3, 2015 at 5:43 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:

On 02/02/2015 09:07 PM, Everett Toews wrote:

On Feb 2, 2015, at 7:24 PM, Sean Dague s...@dague.net
mailto:s...@dague.net
mailto:s...@dague.net mailto:s...@dague.net wrote:

On 02/02/2015 05:35 PM, Jay Pipes 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: ComputeFeatureUnsupportedOnIns__tanceType,
  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
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
http://errors.openstack.org
http://errors.openstack.org.


That could definitely be implemented in the short term, but
if we're
talking about API WG long term evolution, I'm not sure why a
standard
error payload body wouldn't be better.


Agreed. And using the “X-“ prefix in headers has been deprecated for
over 2 years now [1]. I don’t think we should be using it for
new things.

Everett

[1] https://tools.ietf.org/html/__rfc6648
https://tools.ietf.org/html/rfc6648


Ha! Good to know about the X- stuff :) Duly noted!


-jay


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton


__
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


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

2015-02-02 Thread Christopher Yeoh
On Tue, Feb 3, 2015 at 9:05 AM, Jay Pipes jaypi...@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.


So I'm +1 to adding the X-OpenStack-Error-Code header assuming the error
code is unique
across OpenStack APIs and it has a fixed meaning (we never change it,
create a new one if
a project has a need for an error code which is close to the original one
but a bit different)

The X-OpenStack-Error-Help-URI header I'm not sure about. We can't
guarantee that apps will have
access to errors.openstack.org - is there an assumption here that we'd
build/ship an error translation service?

Regards,

Chris
__
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


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

2015-02-02 Thread Jay Pipes

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.


Best,
-jay

__
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


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

2015-02-02 Thread Sean Dague
On 02/02/2015 05:35 PM, Jay Pipes 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.

That could definitely be implemented in the short term, but if we're
talking about API WG long term evolution, I'm not sure why a standard
error payload body wouldn't be better.

The if we are going to having global codes that are just numbers, we'll
also need a global naming registry. Which isn't a bad thing, just
someone will need to allocate the numbers in a separate global repo
across all projects.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
__
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


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

2015-02-02 Thread Ryan Moats
+1 to that idea...

Jay Pipes jaypi...@gmail.com wrote on 02/02/2015 04:35:36 PM:


 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.
__
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


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

2015-02-02 Thread Qin Zhao
Agree with Sean. A short error name in response body would be better for
applications who consume OpenStack. To my understand, the
X-OpenStack-Error-Help-URI proposed by jpipes will be a uri to error
resolution method. Usually, a consumer application needn't to load its
content.
On Feb 3, 2015 9:28 AM, Sean Dague s...@dague.net wrote:

 On 02/02/2015 05:35 PM, Jay Pipes 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.

 That could definitely be implemented in the short term, but if we're
 talking about API WG long term evolution, I'm not sure why a standard
 error payload body wouldn't be better.

 The if we are going to having global codes that are just numbers, we'll
 also need a global naming registry. Which isn't a bad thing, just
 someone will need to allocate the numbers in a separate global repo
 across all projects.

 -Sean

 --
 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


__
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


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

2015-02-02 Thread Ryan Moats
Sigh... hit send too soon and forgot to sign...

+1 to that idea...

Ryan

Jay Pipes jaypi...@gmail.com wrote on 02/02/2015 04:35:36 PM:


 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.__
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


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

2015-02-02 Thread Brant Knudson
On Mon, Feb 2, 2015 at 4:35 PM, Jay Pipes jaypi...@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-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


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

2015-02-02 Thread Feodor Tersin
Hi Ken,

1 imageRef isn't the only attribute, which could receive an image id. There
are kernelId, ramdiskId, and even bdm v2 as well. So we couldn't guess
which attribute has the invalid value.

2 Besides NotFound case, other mixed cases are there. Such as attaching of
a volume. A mountpoint can be busy, or the volume can be used by an other
instance - both cases generate a conflict error. Do you suggest to use
specially formatted message in all such cases (when the same http error
code has several reasons)? But to make a work with Nova API
straightforward, all messages should have this format, even in simplest
cases.

3 How to parse a localized message? A Nova API client shouldn't use en_us
locale only to communicate with Nova, because it should display messages
generated by Nova to an end user.



On Mon, Feb 2, 2015 at 8:28 AM, Ken'ichi Ohmichi ken1ohmi...@gmail.com
wrote:

 2015-01-30 18:13 GMT+09:00 Simon Pasquier spasqu...@mirantis.com:
  On Fri, Jan 30, 2015 at 3:05 AM, Kenichi Oomichi 
 oomi...@mxs.nes.nec.co.jp
  wrote:
 
   -Original Message-
   From: Roman Podoliaka [mailto:rpodoly...@mirantis.com]
   Sent: Friday, January 30, 2015 2:12 AM
   To: OpenStack Development Mailing List (not for usage questions)
   Subject: Re: [openstack-dev] [api][nova] Openstack HTTP error codes
  
   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.
 
  Yeah, current Nova v2 API (not v2.1 API) returns inconsistent messages
  in badRequest responses, because these messages are implemented at many
  places. But Nova v2.1 API can return consistent messages in most cases
  because its input validation framework generates messages
  automatically[1].
 
 
  When you say most cases, you mean JSON schema validation only, right?
  IIUC, this won't apply to the errors described by the OP such as invalid
 key
  name, unknown security group, ...

 Yeah, right.
 I implied that in most cases and I have one patch[1] for covering them.
 By the patch, the sample messages also will be based on the same
 format and be consistent.
 The other choice we have is CamelCase exception as the fist mail, that
 also is interesting.

 Thanks
 Ken Ohmichi

 ---
 [1]: https://review.openstack.org/#/c/151954

 __
 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


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

2015-02-02 Thread Everett Toews
On Feb 2, 2015, at 7:24 PM, Sean Dague s...@dague.netmailto:s...@dague.net 
wrote:

On 02/02/2015 05:35 PM, Jay Pipes 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.orghttp://errors.openstack.org.

That could definitely be implemented in the short term, but if we're
talking about API WG long term evolution, I'm not sure why a standard
error payload body wouldn't be better.

Agreed. And using the “X-“ prefix in headers has been deprecated for over 2 
years now [1]. I don’t think we should be using it for new things.

Everett

[1] https://tools.ietf.org/html/rfc6648

__
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


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

2015-02-01 Thread Ken'ichi Ohmichi
2015-01-30 18:13 GMT+09:00 Simon Pasquier spasqu...@mirantis.com:
 On Fri, Jan 30, 2015 at 3:05 AM, Kenichi Oomichi oomi...@mxs.nes.nec.co.jp
 wrote:

  -Original Message-
  From: Roman Podoliaka [mailto:rpodoly...@mirantis.com]
  Sent: Friday, January 30, 2015 2:12 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [api][nova] Openstack HTTP error codes
 
  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.

 Yeah, current Nova v2 API (not v2.1 API) returns inconsistent messages
 in badRequest responses, because these messages are implemented at many
 places. But Nova v2.1 API can return consistent messages in most cases
 because its input validation framework generates messages
 automatically[1].


 When you say most cases, you mean JSON schema validation only, right?
 IIUC, this won't apply to the errors described by the OP such as invalid key
 name, unknown security group, ...

Yeah, right.
I implied that in most cases and I have one patch[1] for covering them.
By the patch, the sample messages also will be based on the same
format and be consistent.
The other choice we have is CamelCase exception as the fist mail, that
also is interesting.

Thanks
Ken Ohmichi

---
[1]: https://review.openstack.org/#/c/151954

__
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


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

2015-01-30 Thread Brant Knudson
On Thu, Jan 29, 2015 at 5:01 PM, Jay Faulkner j...@jvf.cc wrote:


  On Jan 29, 2015, at 2:52 PM, Kevin Benton blak...@gmail.com wrote:

  Oh, I understood it a little differently. I took parsing of error
 messages here is not the way we’d like to solve this problem as meaning
 that parsing them in their current ad-hoc, project-specific format is not
 the way we want to solve this (e.g. the way tempest does it). But if we had
 a structured way like the EC2 errors, it would be a much easier problem to
 solve.

  So either way we are still parsing the body, the only difference is that
 the parser no longer has to understand how to parse Neutron errors vs. Nova
 errors. It just needs to parse the standard OpenStack error format that
 we come up with.


  This would be especially helpful for things like haproxy or other load
 balancers, as you could then have them put up a static, openstack-formatted
 JSON error page for their own errors and trust the clients could parse them
 properly.

  -Jay



It shouldn't be necessary for proxies to generate openstack-formatted error
pages. A proxy can send a response where the content-type is text/plain and
the client can show the message, treating it as just some text to display.
I think that's all we're expecting a client to do in general, especially
when it doesn't have enough information to actually take some sort of
useful action in response to the error. Clients that get an
openstack-formatted message (with content-type: application/json) can parse
out the message and display that, or look at the error ID and do something
useful.

- Brant
__
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


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

2015-01-30 Thread Everett Toews

On Jan 29, 2015, at 11: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.

Agreed. I’m 100% for having a guideline for errors. Good error messages is one 
of the most important aspects of a good developer experience for an API. I 
suspect that once you propose an error format for one error, people will 
immediately think of a lot of valid reasons to have a formant for many errors.

I did a bit of research into prior art for error messages. The best discussion 
I found on it starts over in JSON-API [1]. It ultimately results in this error 
format [2]. An example would look like

{
  errors: [
{
  id: some-transaction-id,
  href: https://example.org/more/info/about/this/error.html;,
  code: 0054,
  title: foobar must be in the range [foo, bar)
},
{
  id: ...
}
  ]
}

Do we need to use every field in the format? No.
Can we add additional fields as we see fit? Yes.

We need to do what’s best for OpenStack so I’d like to use a format that’s 
somewhat a standard (at the very least it’s clear that the JSON-API folks have 
done a lot of thinking on it) but that’s flexible enough to meet our 
requirements.

I came across some other error formats such as [3] and [4] but found them to be 
a bit complicated or require things we don’t need.

Thoughts on the JSON-API error format or other formats?

Thanks,
Everett

[1] https://github.com/json-api/json-api/issues/7
[2] http://jsonapi.org/format/#errors
[3] https://github.com/blongden/vnd.error
[4] 
https://google-styleguide.googlecode.com/svn/trunk/jsoncstyleguide.xml#Reserved_Property_Names_in_the_error_object


__
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


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

2015-01-30 Thread Simon Pasquier
On Fri, Jan 30, 2015 at 3:05 AM, Kenichi Oomichi oomi...@mxs.nes.nec.co.jp
wrote:

  -Original Message-
  From: Roman Podoliaka [mailto:rpodoly...@mirantis.com]
  Sent: Friday, January 30, 2015 2:12 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [api][nova] Openstack HTTP error codes
 
  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.

 Yeah, current Nova v2 API (not v2.1 API) returns inconsistent messages
 in badRequest responses, because these messages are implemented at many
 places. But Nova v2.1 API can return consistent messages in most cases
 because its input validation framework generates messages automatically[1].


When you say most cases, you mean JSON schema validation only, right?
IIUC, this won't apply to the errors described by the OP such as invalid
key name, unknown security group, ...

Thanks,
Simon



 Thanks
 Ken'ichi Ohmichi

 ---
 [1]:
 https://github.com/openstack/nova/blob/master/nova/api/validation/validators.py#L104

  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

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

2015-01-29 Thread Anne Gentle
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


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

2015-01-29 Thread Roman Podoliaka
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


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

2015-01-29 Thread Sean Dague
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?

 

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

2015-01-29 Thread John Dickinson
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
 

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

2015-01-29 Thread Kevin Benton
I don't understand what you are suggesting here. All of these codes will be
for specific openstack service error conditions. The codes in the link you
provided don't provide any useful information to callers other than more
details about how a web-server is (mis)configured. I didn't see anything
related to Neutron port-binding failures due to mechanism driver errors in
that list. :)


On Thu, Jan 29, 2015 at 9:56 AM, John Dickinson m...@not.mn wrote:

 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: 

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

2015-01-29 Thread Brant Knudson
On Thu, Jan 29, 2015 at 11: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), 

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

2015-01-29 Thread John Dickinson
I think there are two points. First, the original requirement (in the first 
email on this thread) is not what's wanted:

...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.

So adding a response body to parse doesn't solve the problem. The request as I 
read it is to have a set of well-defined error codes to know what happens.

Second, my response is a little tongue-in-cheek, because I think the IIS 
response codes are a perfect example of extending a common, well-known protocol 
with custom extensions that breaks existing clients. I would hate to see us do 
that.

So if we can't subtly break http, and we can't have error response documents, 
then we're left with custom error codes in the particular response-code class. 
eg 461 SecurityGroupNotFound or 462 InvalidKeyName (from the original examples)


--John






 On Jan 29, 2015, at 11:39 AM, Brant Knudson b...@acm.org wrote:
 
 
 
 On Thu, Jan 29, 2015 at 11: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, 

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

2015-01-29 Thread Kevin Benton
Oh, I understood it a little differently. I took parsing of error messages
here is not the way we’d like to solve this problem as meaning that
parsing them in their current ad-hoc, project-specific format is not the
way we want to solve this (e.g. the way tempest does it). But if we had a
structured way like the EC2 errors, it would be a much easier problem to
solve.

So either way we are still parsing the body, the only difference is that
the parser no longer has to understand how to parse Neutron errors vs. Nova
errors. It just needs to parse the standard OpenStack error format that
we come up with.



On Thu, Jan 29, 2015 at 12:04 PM, John Dickinson m...@not.mn wrote:

 I think there are two points. First, the original requirement (in the
 first email on this thread) is not what's wanted:

 ...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.

 So adding a response body to parse doesn't solve the problem. The request
 as I read it is to have a set of well-defined error codes to know what
 happens.

 Second, my response is a little tongue-in-cheek, because I think the IIS
 response codes are a perfect example of extending a common, well-known
 protocol with custom extensions that breaks existing clients. I would hate
 to see us do that.

 So if we can't subtly break http, and we can't have error response
 documents, then we're left with custom error codes in the particular
 response-code class. eg 461 SecurityGroupNotFound or 462 InvalidKeyName
 (from the original examples)


 --John






  On Jan 29, 2015, at 11:39 AM, Brant Knudson b...@acm.org wrote:
 
 
 
  On Thu, Jan 29, 2015 at 11: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
  

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

2015-01-29 Thread Kenichi Oomichi
 -Original Message-
 From: Roman Podoliaka [mailto:rpodoly...@mirantis.com]
 Sent: Friday, January 30, 2015 2:12 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [api][nova] Openstack HTTP error codes
 
 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.

Yeah, current Nova v2 API (not v2.1 API) returns inconsistent messages
in badRequest responses, because these messages are implemented at many
places. But Nova v2.1 API can return consistent messages in most cases
because its input validation framework generates messages automatically[1].

Thanks
Ken'ichi Ohmichi

---
[1]: 
https://github.com/openstack/nova/blob/master/nova/api/validation/validators.py#L104

 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

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

2015-01-29 Thread Jay Faulkner

On Jan 29, 2015, at 2:52 PM, Kevin Benton 
blak...@gmail.commailto:blak...@gmail.com wrote:

Oh, I understood it a little differently. I took parsing of error messages 
here is not the way we’d like to solve this problem as meaning that parsing 
them in their current ad-hoc, project-specific format is not the way we want to 
solve this (e.g. the way tempest does it). But if we had a structured way like 
the EC2 errors, it would be a much easier problem to solve.

So either way we are still parsing the body, the only difference is that the 
parser no longer has to understand how to parse Neutron errors vs. Nova errors. 
It just needs to parse the standard OpenStack error format that we come up 
with.


This would be especially helpful for things like haproxy or other load 
balancers, as you could then have them put up a static, openstack-formatted 
JSON error page for their own errors and trust the clients could parse them 
properly.

-Jay



On Thu, Jan 29, 2015 at 12:04 PM, John Dickinson 
m...@not.mnmailto:m...@not.mn wrote:
I think there are two points. First, the original requirement (in the first 
email on this thread) is not what's wanted:

...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.

So adding a response body to parse doesn't solve the problem. The request as I 
read it is to have a set of well-defined error codes to know what happens.

Second, my response is a little tongue-in-cheek, because I think the IIS 
response codes are a perfect example of extending a common, well-known protocol 
with custom extensions that breaks existing clients. I would hate to see us do 
that.

So if we can't subtly break http, and we can't have error response documents, 
then we're left with custom error codes in the particular response-code class. 
eg 461 SecurityGroupNotFound or 462 InvalidKeyName (from the original examples)


--John






 On Jan 29, 2015, at 11:39 AM, Brant Knudson 
 b...@acm.orgmailto:b...@acm.org wrote:



 On Thu, Jan 29, 2015 at 11:41 AM, Sean Dague 
 s...@dague.netmailto: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.commailto:annegen...@justwriteclick.com wrote:
 
 
  On Thu, Jan 29, 2015 at 10:33 AM, Eugeniya Kudryashova
  ekudryash...@mirantis.commailto: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:8774http://192.168.122.195:8774/
 
  X-Auth-Project-Id: demo
 
  Accept-Encoding: gzip, deflate, compress
 
  Content-Length: 189
 
  Accept: