On Mon, May 20, 2019, at 05:40, Lajos Katona wrote:
Thanks Chris for the reply, let's wait for keystone folks for comments.
Hi!
On 2019. 05. 17. 13:42, Chris Dent wrote:
On Fri, 17 May 2019, Lajos Katona wrote:
keystoneauth1 expects the http body in case of for example http404 to be something like this (python dict comes now): body= {'error': {'message': 'Foooooo', 'details': 'Baaaaar'}} see: https://protect2.fireeye.com/url?k=e824ec9f-b4f7fcf7-e824ac04-8691b328a8b8-1c7b10b9a8d8e9c8&q=1&u=https%3A%2F%2Fopendev.org%2Fopenstack%2Fkeystoneauth%2Fsrc%2Fbranch%2Fmaster%2Fkeystoneauth1%2Fexceptions%2Fhttp.py%23L406-L415
But placement started to adopt one suggestion from the API-SIG: http://specs.openstack.org/openstack/api-wg/guidelines/errors.html,
and that is something like this (again python): body={'errors': [{'status': 404, 'title': 'Not Found', 'detail': 'The resource could not be found.... ', 'request_id': '...'}]}
Thanks for all the detail in this message and on the bug report. It helps make understanding what's going on a lot easier.
As you've discovered placement is following the guidelines for how errors are supposed to be formatted. If keystoneauth1 can't speak that format, that's probably the primary bug.
[snipped]
Make keystoneauth1 interpret two diferent types of errors response: the one it does, and the one in the api-sig guidelines. Note that I've yet to see any context where there is more than one error in the list, so it is always errors[0] that gets inspected.
We'll happily accept patches to keystoneauth that make it compliant with the API-SIG's guidelines (as long as it is backwards compatible). I gotta say, though, this guideline on error handling really takes me aback. Why should a single HTTP request ever result in a list of errors, plural? Is there any standard, pattern, or example *outside* of OpenStack where this is done or recommended? Why? Colleen