Open Stack

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

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