ccab6fed46
The InstancePCIRequest.request_id is used to correlate allocated PciDevice objects with the InstancePCIRequest object triggered the PCI allocation. For neutron port based PCI requests the IstancePCIRequest.request_id was already set to a generated UUID by nova. But for Flavor based request the request_id was kept None. The placement PCI scheduling code depends on the request_id to be a unique identifier of the request. So this patch starts filling the request_id for flavor based requests as well. This change showed than in some places nova still uses the request_id == None condition to distinguish between flavor based and neutron based requests. This logic is now adapted to use the newer and better InstancePCIRequest.source based approach. Also we took the opportunity to move the logic of querying PCI devices allocated to an instance to the Instance ovo. This change fills the request_id for newly created flavor based InstancePCIRequest ovos. But the change in logic to use the InstancePCIRequest.source property instead of the request_id == None condition works even if the request_id is None for already existing InstancePCIRequest objects. So this patch does not include a data migration logic to fill request_id for existing objects. blueprint: pci-device-tracking-in-placement Change-Id: I53e03ff7a0221db682b043fb6d5adba3f5c9fdbe |
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| gate | ||
| nova | ||
| playbooks | ||
| releasenotes | ||
| roles | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .pre-commit-config.yaml | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| bindep.txt | ||
| mypy-files.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
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 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:
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: