08337cccb0
Change I1aa3ca6cc70cef65d24dec1e7db9491c9b73f7ab in Queens, which was backported through to Newton, introduced a regression when listing deleted servers with a marker because it assumes that if BuildRequestList.get_by_filters does not raise MarkerNotFound that the marker was found among the build requests and does not account for that get_by_filters method short-circuiting if filtering servers with deleted/cleaned/limit=0. The API code then nulls out the marker which means you'll continue to get the marker instance back in the results even though you shouldn't, and that can cause an infinite loop in some client-side tooling like nova's CLI: nova list --deleted --limit -1 This adds a functional recreate test for the regression which will be updated when the bug is fixed. NOTE(mriedem): In this backport we get the PlacementFixture from the usual nova_fixtures import since change Idaed39629095f86d24a54334c699a26c218c6593 is not in Rocky. Also, test_concurrent_request_server_group_members_over_quota leaks deleted servers from cell0 for some reason in Rocky which can make this test intermittently fail. This is not a problem after Rocky for some reason. To avoid intermittent failures due to that leak, the test is modified to filter on the name of the server created in the test only. Change-Id: I324193129acb6ac739133c7e76920762a8987a84 Related-Bug: #1849409 (cherry picked from commit |
||
---|---|---|
api-guide/source | ||
api-ref/source | ||
contrib | ||
devstack | ||
doc | ||
etc/nova | ||
gate | ||
nova | ||
placement-api-ref | ||
playbooks/legacy | ||
releasenotes | ||
tools | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.mailmap | ||
.stestr.conf | ||
.zuul.yaml | ||
CONTRIBUTING.rst | ||
HACKING.rst | ||
LICENSE | ||
MAINTAINERS | ||
README.rst | ||
babel.cfg | ||
bindep.txt | ||
lower-constraints.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: