Balazs Gibizer
284ea72e96
We saw in the field that the pci_devices table can end up in inconsistent state after a compute node HW failure and re-deployment. There could be dependent devices where the parent PF is in available state while the children VFs are in unavailable state. (Before the HW fault the PF was allocated hence the VFs was marked unavailable). In this state this PF is still schedulable but during the PCI claim the handling of dependent devices in the PCI tracker fill fail with the error: "Attempt to consume PCI device XXX from empty pool". The reason of the failure is that when the PF is claimed, all the children VFs are marked unavailable. But if the VF is already unavailable such step fails. One way the deployer might try to recover from this state is to remove the VFs from the hypervisor and restart the compute agent. The compute startup already has a logic to delete PCI devices that are unused and not reported by the hypervisor. However this logic only removed devices in 'available' state and ignored devices in 'unavailable' state. If a device is unused and the hypervisor is not reporting the device any more then it is safe to delete that device from the PCI tracker. So this patch extends the logic to allow deleting 'unavailable' devices. There is a small window when dependent PCI device is in 'unclaimable' state. From cleanup perspective this is an analogous state. So it is also added to the cleanup logic. Related-Bug: #1969496 Change-Id: If9ab424cc7375a1f0d41b03f01c4a823216b3eb8
==============
OpenStack Nova
==============
.. image:: https://governance.openstack.org/tc/badges/nova.svg
:target: https://governance.openstack.org/tc/reference/tags/index.html
.. Change things from this point on
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, 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:
- `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.
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/