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
