<div dir="ltr">Ideally there would need to be a way to replicate <a href="http://errors.openstack.org">errors.openstack.org</a> 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<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 February 2015 at 00:35, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/29/2015 12:41 PM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Correct. This actually came up at the Nova mid cycle in a side<br>
conversation with Ironic and Neutron folks.<br>
<br>
HTTP error codes are not sufficiently granular to describe what happens<br>
when a REST service goes wrong, especially if it goes wrong in a way<br>
that would let the client do something other than blindly try the same<br>
request, or fail.<br>
<br>
Having a standard json error payload would be really nice.<br>
<br>
{<br>
      fault: ComputeFeatureUnsupportedOnIns<u></u>tanceType,<br>
      messsage: "This compute feature is not supported on this kind of<br>
instance type. If you need this feature please use a different instance<br>
type. See your cloud provider for options."<br>
}<br>
<br>
That would let us surface more specific errors.<br>
</blockquote></span>
<snip><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Standardization here from the API WG would be really great.<br>
</blockquote>
<br></span>
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?<br>
<br>
Something like:<br>
<br>
X-OpenStack-Error-Code: 1234<br>
X-OpenStack-Error-Help-URI: <a href="http://errors.openstack.org/1234" target="_blank">http://errors.openstack.org/<u></u>1234</a><br>
<br>
That way is completely backwards compatible (since we wouldn't be changing response payloads) and we could handle i18n entirely via the HTTP help service running on <a href="http://errors.openstack.org" target="_blank">errors.openstack.org</a>.<br>
<br>
Best,<br>
-jay<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Duncan Thomas</div>
</div>