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

Brant Knudson blk at acm.org
Fri Jan 30 15:12:46 UTC 2015

On Thu, Jan 29, 2015 at 5:01 PM, Jay Faulkner <jay at jvf.cc> wrote:

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

- Brant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150130/e7820326/attachment.html>

More information about the OpenStack-dev mailing list