Balazs Gibizer
1cd1c472bd
The RPC handler build_and_run_instance has a normal set of error handler decorators but that call immediately spawns a separate thread and does not wait for its result so it cannot get any exceptions. Therefore the error handling should happen inside the thread. And it does. Mostly. The _locked_do_build_and_run_instance is the function run by the thread and it calls _do_build_and_run_instance. The _do_build_and_run_instance has `except Exception` handling dropping the active exception and returning an error value instead. So most of the exceptions are handled by _do_build_and_run_instance without going through any of the error decorators. Whatever exception still bubbles up from _do_build_and_run_instance are going through the error handling decorators top of _do_build_and_run_instance. The only source of exception outside of _do_build_and_run_instance but within _locked_do_build_and_run_instance is delete_allocation_for_instance. Exception from that call does not go though any error handling decorators. These error decorators has multiple tasks: * wrap_exception calls _emit_legacy_exception_notification and _emit_versioned_exception_notification so sending error notifications * reverts_task_state sets instance.task_state to None * wrap_instance_fault records InstanceFault object to the DB So there are two cases when error happens but the decorators are not called: * _do_build_and_run_instance catches the exception, does its own error handling and cleanup and then returns an error value. The task state revert and the InstanceFault creation is replicated to the individual cleanup sections here. Note that notification sending is not missing either as that is handled by the _build_and_run_instance called from _do_build_and_run_instance. * delete_allocation_for_instance raises when called from _locked_do_build_and_run_instance. We reach this call if _do_build_and_run_instance failed already and did its own cleanup. So again task state are already reset and InstanceFault already recorded for the original fault and notification already sent. So the only changes here is to add a note to build_and_run_instance so that the real error handling are deeper in the stack so that readers will not think error handling happen on top of the call stack. There was two unit test cases that partially relied on the wrong assumption that exceptions propagate to build_and_run_instance. They could make that wrong assumption because the SpawnIsSynchronousFixture simulates the GreenThread interface wrongly. The goal of that fixture is to make any spawn (and spawn_n) call synchronous meaning the function passed in is executed right away before spawn returns. That is OK. But the fixture forgot that if the function raises then such exception is now raised by spawn. Such a thing never happens with a normal spawn. The exception (and the function return value) only propagated when GreenThread.wait() is called. So this patch fixes the fixture and corrects the two unit tests as well. Change-Id: I440fff6663d0663fb1630dd096f352403982aa37
============== OpenStack Nova ============== OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of compute technologies, including: libvirt (KVM, Xen, LXC and more), VMware and OpenStack Ironic. Use the following resources to learn more. API --- To learn how to use Nova's API, consult the documentation available online at: - `Compute API Guide <https://docs.openstack.org/api-guide/compute/>`__ - `Compute API Reference <https://docs.openstack.org/api-ref/compute/>`__ For more information on OpenStack APIs, SDKs and CLIs in general, refer to: - `OpenStack for App Developers <https://www.openstack.org/appdev/>`__ - `Development resources for OpenStack clouds <https://developer.openstack.org/>`__ Operators --------- To learn how to deploy and configure OpenStack Nova, consult the documentation available online at: - `OpenStack Nova <https://docs.openstack.org/nova/>`__ 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: - `Bug Tracker <https://bugs.launchpad.net/nova>`__ 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. To understand better the processes that the team is using, please refer to the `Process document <https://docs.openstack.org/nova/latest/contributor/process.html>`__. Further developer focused documentation is available at: - `Official Nova Documentation <https://docs.openstack.org/nova/>`__ - `Official Client Documentation <https://docs.openstack.org/python-novaclient/>`__ 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: - `Nova Specs <http://specs.openstack.org/openstack/nova-specs/>`__ .. _Summit: https://www.openstack.org/summit/ .. _Project Team Gathering: https://www.openstack.org/ptg/