Top posting to continue the discussion in another thread. [openstack-dev] [all] [api] Erring is Caring http://lists.openstack.org/pipermail/openstack-dev/2015-March/060314.html
Everett On Feb 4, 2015, at 10:29 AM, Duncan Thomas <[email protected]<mailto:[email protected]>> wrote: Ideally there would need to be a way to replicate errors.openstack.org<http://errors.openstack.org/> 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 On 3 February 2015 at 00:35, Jay Pipes <[email protected]<mailto:[email protected]>> wrote: On 01/29/2015 12:41 PM, Sean Dague wrote: Correct. This actually came up at the Nova mid cycle in a side conversation with Ironic and Neutron folks. HTTP error codes are not sufficiently granular to describe what happens when a REST service goes wrong, especially if it goes wrong in a way that would let the client do something other than blindly try the same request, or fail. Having a standard json error payload would be really nice. { fault: ComputeFeatureUnsupportedOnInstanceType, messsage: "This compute feature is not supported on this kind of instance type. If you need this feature please use a different instance type. See your cloud provider for options." } That would let us surface more specific errors. <snip> Standardization here from the API WG would be really great. 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? Something like: X-OpenStack-Error-Code: 1234 X-OpenStack-Error-Help-URI: http://errors.openstack.org/1234 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 errors.openstack.org<http://errors.openstack.org/>. Best, -jay __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe<http://[email protected]/?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]<mailto:[email protected]>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
