Reject live migration if there are virtual persistent memory resources.
Otherwise, if dest host has same vpmem backend file name as that used
by instance, live migration will succeed and these files will be used
but not tracked in Nova; if dest host has no those vpmems, it will
trigger an error.
Change-Id: I900f74d482fc87da5b1b5ec9db2ad5aefcfcfe7a
Closes-bug: #1863605
Implements: blueprint support-live-migration-with-virtual-persistent-memory
This patch poisons the synchronized decorator in the unit test
to prevent adding you synchronized methods without the fair=True
flag.
Change-Id: I739025dacbcaa0f7adbe612c064f979bf6390880
Related-Bug: #1864122
The test_unshelve_offloaded_fails_due_to_neutron could fail due to race
condition. The test case only waits for the first instance.save() call
at [1] but the allocation delete happens after it. This causes that the
test case can still see the allocation of the offloaded server in
placement.
The fix makes sure that the test waits for the second instance.save() by
checking for the host of the instance.
[1] https://github.com/openstack/nova/blob/stable/rocky/nova/compute/manager.py#L5274-L5288
Related-Bug #1862633
Change-Id: Ic1c3d35749fbdc7f5b6f6ec1e16b8fcf37c10de8
This is mostly code motion from the nova.virt.images module into privsep
to allow for both privileged and unprivileged calls to be made.
A privileged_qemu_img_info function is introduced allowing QEMU to
access devices requiring root privileges, such as host block devices.
Change-Id: I5ac03f923d9d181d22d44d8ec8fbc31eb0c3999e
While introducing PROJECT_READER_OR_SYSTEM_READER in policy
- https://review.opendev.org/#/c/706672
I added those rules in system_reader list in test_policy.
Let's maintain them in separate list for easy read. There
are going to be more policies in this list.
Partial implement blueprint policy-defaults-refresh
Change-Id: Ice3d79f0803efad60236e55b55bebd681056564c
The SDK API tests provide another set of verification of nova
behavior. In a perfect world, as we add new microversions to
nova, we'd add support for the microversion first to SDK along
with a test that should work if the MV isn't there, and then
adding the microversion the test should still work - which would
allow us to make sure SDK is always up to date with the very
latest and greatest nova api.
Change-Id: I2406bd6d9e69e33e57b715ff0812c5770b1b53d8
As of now, questions on the mailing list are going unanswered, and the
Nova team does not have a clear representative owner for the driver
to which bugs and other reports can be directed. There does not appear
to be a CI system running tests for the driver anymore, and the latest
indication from the community[1] points to it being potentially broken with
devstack.
This patch starts the deprecation timer for the driver and/or serves
as a flare to gauge interest (or lack thereof) in continuing to maintain
the driver.
1: http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013066.html
Change-Id: Ie39e9605dc8cebff3795a29ea91dc08ee64a21eb
When the resource tracker has to lock a compute host for updates or
inspection, it uses a single semaphore. In most cases, this is fine, as
a compute process only is tracking one hypervisor. However, in Ironic, it's
possible for one compute process to track many hypervisors. In this
case, wait queues for instance claims can get "stuck" briefly behind
longer processing loops such as the update_resources periodic job. The
reason this is possible is because the oslo.lockutils synchronized
library does not use fair locks by default. When a lock is released, one
of the threads waiting for the lock is randomly allowed to take the lock
next. A fair lock ensures that the thread that next requested the lock
will be allowed to take it.
This should ensure that instance claim requests do not have a chance of
losing the lock contest, which should ensure that instance build
requests do not queue unnecessarily behind long-running tasks.
This includes bumping the oslo.concurrency dependency; fair locks were
added in 3.29.0 (I37577becff4978bf643c65fa9bc2d78d342ea35a).
Change-Id: Ia5e521e0f0c7a78b5ace5de9f343e84d872553f9
Related-Bug: #1864122
In some tests, we were doing an import with a full module path. This has
the side effect of importing every submodule on that path, which led to
some confusing side effects. Use 'import foo from bar' syntax instead
and clean up the damage.
Change-Id: I91a289630f31674dec1d785d67b5acda173b7d7e
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Similar to change I8ae352ff3eeb760c97d1a6fa9d7a59e881d7aea1, if
we're processing a network-vif-deleted event while an instance
is being deleted, the asynchronous interface detach could fail
because the guest is gone from the hypervisor. The existing code
for handling this case was using a stale guest object so this
change tries to refresh the guest from the hypervisor and if the
guest is gone, the Host.get_guest() method should raise an
InstanceNotFound exception which we just trap, log and return.
Change-Id: Ic4c870cc5078d3f7ac6b2f96f8904c2a47de418e
Closes-Bug: #1797966
This adds new defaults roles in os-attach-interfaces API policies.
- GET rules are made granular and default to System or project reader
- Other policies are default to system admin or project member.
Also add tests to simulates the future where we drop the deprecation
fall back in the policy by overriding the rules with a version where
there are no deprecated rule options. Operators can do the same by
adding overrides in their policy files that match the default but
stop the rule deprecation fallback from happening.
Partial implement blueprint policy-defaults-refresh
Change-Id: Ic405544560ae75ad88c10b8ff6d5048b3728cd2b
We have a custom of naming the directory after the API. Reinforce that
here.
Change-Id: I5bf68aacc1d987400a91467835c4b55f03c18beb
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The API URL is '/os-keypairs', not '/keypairs'. Attempting to use these
pagination links as-is will result in a HTTP 404 (Not Found).
Change-Id: Ic04568caecc138e6016418f6878d031c4a0d3fb4
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Closes-bug: #1866373
Zuul