<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 5:01 PM, Jay Faulkner <span dir="ltr"><<a href="mailto:jay@jvf.cc" target="_blank">jay@jvf.cc</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<br>
<div><span class="">
<blockquote type="cite">
<div>On Jan 29, 2015, at 2:52 PM, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<div>Oh, I understood it a little differently. I took "<span style="font-size:12.8000001907349px">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.</span><br>
</div>
<div><span style="font-size:12.8000001907349px"><br>
</span></div>
<div><span style="font-size:12.8000001907349px">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.</span></div>
<div class="gmail_extra"><br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>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.</div><span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>-Jay</div></font></span><div><div class="h5">
<br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br></div></div></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>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.<br><br></div><div>- Brant<br><br></div></div><br></div></div>