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

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 mailto:duncan.tho...@gmail.com>> wrote: Ideally there would need

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

Argh. Wrong thread. Sorry. I was aiming for one about logging :( On 14 Feb 2015 01:48, "Jay Pipes" wrote: > On 02/12/2015 09:59 PM, Robert Collins wrote: > >> On 5 February 2015 at 13:20, Rochelle Grober >> wrote: >> >>> Duncan Thomas [mailto:duncan.tho...@gmail.com] on Wednesday, February >>> 0

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

On 02/12/2015 09:59 PM, Robert Collins wrote: On 5 February 2015 at 13:20, Rochelle Grober 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 mem

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

On 5 February 2015 at 13:20, Rochelle Grober 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

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

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

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

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 globa

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

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

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

On 30 January 2015 at 09:04, John Dickinson 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

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

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 mailto:jaypi...@gmail.com>> wrote: On 02/02/2015 09:07 PM, Everett Toews wrote: On

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

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 wrote: > On 02/02/2015 09:07 PM, Everett Toews wrote: > >> On Feb 2, 2015, at 7:24 PM, Sean Dague > > wrote: >> >> On 02/02/2015 05:35 PM, Jay Pipes wrote

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

On 02/02/2015 09:07 PM, Everett Toews wrote: On Feb 2, 2015, at 7:24 PM, Sean Dague 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 Neu

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

On Feb 2, 2015, at 7:24 PM, Sean Dague 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 sufficientl

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

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

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

On Mon, Feb 2, 2015 at 4: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 R

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

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

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

On Tue, Feb 3, 2015 at 9:05 AM, 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 R

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

Sigh... hit send too soon and forgot to sign... +1 to that idea... Ryan Jay Pipes 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

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

+1 to that idea... Jay Pipes 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-Er

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

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 w

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

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

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

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

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

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

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

On Thu, Jan 29, 2015 at 5:01 PM, Jay Faulkner wrote: > > On Jan 29, 2015, at 2:52 PM, Kevin Benton 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-ho

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

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

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

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

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

On Jan 29, 2015, at 2:52 PM, Kevin Benton mailto: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

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

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 structu

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

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 lik

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

On Thu, Jan 29, 2015 at 11:41 AM, 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 wr

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

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 re

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

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 wh

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

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

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. Thanks, Roman On Th

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

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

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

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 diff