236bb54493
Originally, in change Id188d48609f3d22d14e16c7f6114291d547a8986 we added a re-initialization of volumes, encryptors, and vifs to hard reboot. When creating the libvirt domain and network, we were waiting for vif plug events from neutron when we replugged the vifs. Then, we started seeing timeouts in the linuxbridge gate job because compute was timing out waiting for plug events from neutron during a hard reboot. It turns out that the behavior of neutron plug events depends on what vif type we're using and we're also using a stale network info_cache throughout the hard reboot code path, so we can't be 100% sure we know which vifs to wait for plug events from anyway. We coincidentally get some info_cache refreshes from network-changed events from neutron, but we shouldn't rely on that. Ideally, we could do something like wait for an unplug event after we unplug the vif, then refresh the network_info cache, then wait for the plug event. BUT, in the case of the os-vif linuxbridge unplug method, it is a no-op, so I don't think we could expect to get an unplug event for it (and we don't see any network-vif-unplugged events sent in the q-svc log for the linuxbridge job during a hard reboot). Closes-Bug: #1744361 Change-Id: Ib0cf5d55750f13d0499a570f14024dca551ed4d4 |
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| contrib | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| gate | ||
| nova | ||
| placement-api-ref/source | ||
| playbooks/legacy/nova-lvm | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| babel.cfg | ||
| bindep.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tests-py3.txt | ||
| tox.ini | ||
README.rst
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: