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:
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
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
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
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
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
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
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
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
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
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
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
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
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
+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
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
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?
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
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
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
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
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
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
: [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
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
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
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
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
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
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
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
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
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
-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
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
35 matches
Mail list logo
