8a3e7c5a95
The API-sig has a guideline[1] for including error codes in error responses to help distinguish errors with the same status code from one another. This change provides a simplest-thing-that-could- possibly-work solution to make that go. This solution comes about after a few different constraints and attempts: * We would prefer to go on using the existing webob.exc exceptions, not make subclasses. * We already have a special wrapper around our wsgi apps to deal with setting the json_error_formatter. * Though webob allows custom Request and Response objects, it uses the default Response object as the parent of the HTTP exceptions. * The Response object accepts kwargs, but only if they can be associated with known attributes on the class. Since we can't subclass... * The json_error_formatter method is not passed the raw exception, but it does get the current WSGI environ * The webob.exc classes take a 'comment' kwarg that is not used, but is also not passed to the json_error_formatter. Therefore, when we raise an exception, we can set 'comment' to a code and then assign that comment to a well known field in the environ and if that environ is set in json_error_formatter, we can set 'code' in the output. This is done in a new microversion, 1.23. Every response gets a default code 'placement.undefined_code' from 1.23 on. Future development will add specific codes where required. This change adds a stub code for inventory in use when doing a PUT to .../inventories but the name may need improvement. [1] http://specs.openstack.org/openstack/api-wg/guidelines/errors.html Implements blueprint placement-api-error-handling Change-Id: I9a833aa35d474caa35e640bbad6c436a3b16ac5e |
||
|---|---|---|
| api-ref/source | ||
| doc | ||
| etc/nova | ||
| gate | ||
| nova | ||
| placement-api-ref/source | ||
| releasenotes/notes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| babel.cfg | ||
| bindep.txt | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
Team and repository tags
OpenStack Nova
OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of compute technologies, including: libvirt (KVM, Xen, LXC and more), Hyper-V, VMware, XenServer, OpenStack Ironic and PowerVM.
Use the following resources to learn more.
API
To learn how to use Nova's API, consult the documentation available online at:
For more information on OpenStack APIs, SDKs and CLIs in general, refer to:
Operators
To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:
In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at:
Developers
For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst.
Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests.
Further developer focused documentation is available at:
Other Information
During each Summit and Project Team Gathering, we agree on what the whole community wants to focus on for the upcoming release. The plans for nova can be found at: