The weigher is unable to get the right image metadata for existing
instances if they are not already on the HostState.
Change-Id: I5bccf854662ecffe1d469bacc6e4afcb746d6b4d
Signed-off-by: Sylvain Bauza <sbauza@redhat.com>
Currently, vTPM secrets are deleted from Barbican any time instance
disks are deleted when driver.destroy() is called. This is fine if the
instance is also being deleted but if it's not, such as during a resize
revert, it will fail with the following error:
nova.exception.Invalid: Refusing to create an emulated TPM with no
secret!
which will bubble up to the API as a HTTP 500.
This moves deletion of the vTPM secret from Barbican from the libvirt
driver destroy() path to the compute manager _delete_instance() path so
that the vTPM secret is deleted only if the instance is being deleted.
Closes-Bug: #2125030
Change-Id: I1a43dc0502e1e65b4ef0348610f5eddb43dbff02
Signed-off-by: melanie witt <melwittt@gmail.com>
We have a centralized nova.utils.cooperative_yield() instead of
time.sleep(0). It is better as it allows to turn off the sleep calls
when the service runs in threaded mode.
Change-Id: I625daec79ee5b7f8b92116f450e21f997cef0546
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
This reproduces the bug where an attempt to revert a resize from a
flavor with vTPM to a different flavor with vTPM results in the revert
failing and the instance going into ERROR state when storage is not
shared.
Because of the lack of test coverage of vTPM with non-shared storage,
this change also just adds a subclass to run all of the vTPM functional
tests with the test environment mocked to behave as though storage is
not shared between compute hosts.
A bug fix will follow these functional tests.
Related-Bug: #2125030
Change-Id: I49745a8ba78e1ea6a1b009bccab32a002cb6afb0
Signed-off-by: melanie witt <melwittt@gmail.com>
Previous patches removed direct eventlet usage from nova-conductor so
now we can run it with native threading as well. This patch documents
the possibility and switches both nova-conductor process to native
threading mode in the nova-next job.
Change-Id: If26c0c7199cbda157f24b99a419697ecb6618fa6
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
Replace the remaining time.sleep calls use to trigger eventlet yield
to the existing nova.utils.cooperative_yield() call. This will help
us to disable such yielding in when the service is running in threading
mode and eventually drop the whole thing when nova removes eventlet.
Change-Id: I6b3fcba13f4d1c41d1fac2efe3cb4a943e66f8bb
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
There is two intermittently failing tests we need to ignore for now so
this patch extends the list.
Closes-Bug: #2125185
Change-Id: I8d440013c84ae1dac4e2a1f661fc31138944b032
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
Creating a new admin context as we can't reuse the RequestSpec user
context in order to hydrate InstanceList with the full list of instances
from the host and not only the ones from the user.
Closes-Bug: #2125052
Change-Id: Ibbd80324c17be6546ecd8b80f908ac5bbab5abd0
Signed-off-by: Sylvain Bauza <sbauza@redhat.com>
Added a functional regression test that shows that a second instance
fails on a host.
Related-Bug: #2125052
Change-Id: I14c1464d638a8c0d55e6a69ec22e0b83567c1797
Signed-off-by: Sylvain Bauza <sbauza@redhat.com>
This is a pure refactor so not having any unit test change actually
signals that the refactor did not change the existing behavior which is
good.
The unit test run on this patch only covers the eventlet mode but higher
in the series we run unit test with native threading mode in a separate
job that will complement the coverage for this patch.
Change-Id: Iafc96c93a0d4c406b77902942b2940653441fe38
Signed-off-by: Kamil Sambor <kamil.sambor@gmail.com>
This change fixes string format specifier from $ to % for
correct formatting.
Closes-Bug: #2123840
Signed-off-by: Rajesh Tailor <ratailor@redhat.com>
Change-Id: I04f6e1ba3eff443d40a13c6fe2d0b77a78a020e6
Add file to the reno documentation build to show release notes for
stable/2025.2.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2025.2.
Sem-Ver: feature
Change-Id: I7d967c1d5b1ac7fa2e601acfa25c3b5c3880056e
Signed-off-by: OpenStack Release Bot <infra-root@openstack.org>
Generated-By: openstack/project-config:roles/copy-release-tools-scripts/files/release-tools/add_release_note_page.sh
This is a major timesaver for repos the size of nova. This broke
recently due to changes in flake8 itself. This removes some
needless complexity to make it work again. It also removes the
suggestion to use pre-commit which has nothing to do with this
target, which also stings more when pre-commit is breaking things
which is why you're using this in the first place.
Change-Id: Ieb150bf0931ad8031ca83bae1f206075a9f505e2
Signed-off-by: Dan Smith <dansmith@redhat.com>
The /os-hypervisors/detail API endpoint was experiencing significant
performance issues in environments with many compute nodes when using
microversion 2.88 or higher, as it made sequential RPC calls to gather
uptime information from each compute node.
This change optimizes uptime retrieval by:
* Adding uptime to periodic resource updates sent by nova-compute to the
database, eliminating synchronous RPC calls during API requests
* Restricting RPC-based uptime retrieval to hypervisor types that support
it (libvirt and z/VM), avoiding unnecessary calls that would always fail
* Preferring cached database uptime data over RPC calls when available
Closes-Bug: #2122036
Assisted-By: Claude <noreply@anthropic.com>
Change-Id: I5723320f578192f7e0beead7d5df5d7e47d54d2b
Co-Authored-By: Sylvain Bauza <sbauza@redhat.com>
Signed-off-by: Sean Mooney <work@seanmooney.info>
This changes the PCI Placement translator edge case handling logic to
resolve a bug preventing VM deletion.
If a device is allocated but removed from the dev_spec then we need to
keep the device in Placement otherwise the Placement update will be
rejected as we are trying to delete an RP that has allocations. This
prevent the deletion of a VM that is using this removed device.
The alternative would be to not allow the nova-compute service to
start if it detects this situation. However this situation can
happen in at least two very different cases:
1. The admin removed a dev_spec. In this case adding the dev_spec back,
removing the VM, then removing the dev_spec is the right course of
action and nova-compute failing to start would be OK to enforce this.
2. A device disappeared as the HW is died. In this case not allowing the
nova-compute to start up would prevent the admin to migrate the
other VMs away from the host before doing a HW replacement.
Note that this is fairly complex change due to the fact that based on
purely the PciDevice object we cannot differentiate between the two
cases:
1. A PciDevice object is being removed as the related device spec is
removed from the configuration or the device is disappeared from
the hypervisor.
2. A PciDevice object was held back for a while as the device spec is
removed (or the device disappeared from the hypervisor) while the
device was allocated to a VM. And now that VM is undergoing deletion.
In both case the PCI in Placement logic sees a PciDevice object in
dev.status.REMOVED and dev.instance_uuid = None. However the two cases
require different handling.
1. The related inventory can be removed from Placement
2. The related inventory cannot be removed from Placement as it is still
being allocated to the VM that is undergoing deletion.
The second case is due to the sequence of events during a VM deletion
being:
* We destroy the VM on the hypervisor
* We update the PCI tracker to free the device. As the device was held back
the tracker not just frees the device but removes it as well as it is
not configured any more in the dev_spec so it should not go to
AVAILABLE state.
* When the PCI tracker is updated it calls the PCI in Placement logic
to update Placement inventories as well. At this point the VM deletion
still in progress and the VM's allocation hasn't been deleted in
Placement, so the Placement inventory cannot be removed as it is still
allocated.
* After the resource tracker update is finished the compute manager
deletes the VM's allocation in Placement.
So in this edge case we temporarily keep the Placement inventory and
only remove that in a subsequent periodic run where we are sure the
VM's allocation is gone. This means there is a time window when
the Placement inventory shows an extra resource even though that
resource has already been removed from the PCI tracker. During this
window the scheduler might select a host based on this ghost inventory
and the compute resource tracker will reject the boot request forcing
a normal re-schedule.
Closes-Bug: #2115905
Change-Id: Ie9d311ea9f59ff49593003e3773b690dd36fdeb2
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
The PCI tracker handles the case when a device spec is removed from
the configuration while a device is still being allocated. It keeps the
device until the VM is deleted to avoid inconsistencies.
However the full removal of such a device needs not just the VM deletion,
but also a nova-compute restart. The device tracker just frees the
device during VM deletion but does not removed them until the next
nova-compute startup. This allows the device to be re-allocated by
another VM even though the device is not allowed by a device_spec.
This change adds yet another in memory dict to the pci tracker to track
these devices that are only kept until they are freed. Then during
free() this list is consulted and if the device is in the list then the
device is marked for removal as well.
This kills two birds with one stone:
* We prevent the re-allocation of the device as the state of the device
will be set to REMOVED not AVAILABLE during VM deletion.
* As PCI in Placement relies on the state of the device to decide what
to track in placement, this change makes sure that a device that
needs to be removed, is now removed from placement too. Note that we have
another bug that prevents this removal for now. But at least the
reproducers of that bug now starts to behave the same regardless of
how many device belongs to the same RP in placement.
Related-Bug: #2115905
Change-Id: I63c8fb2669a3c6b3adb77d210c0f9b39d3657c80
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
Both the PCI tracker and the PCI in Placement logic handles the case
when a device spec is removed from the configuration while a device
is still being allocated.
However there are edge cases in PCI in Placement that it not handled
well. Namely that if the VM with this allocation is deleted, then
depending on the amount of VFs the PF had originally, the logic might
try to delete the RP before the allocation is removed. That is
rejected by Placement. This prevent the deletion of such a VM and
therefore prevents one of the ways the original inconsistency can be
Note that with this patch we see two additional behaviors worth
mentioning:
* When the VM is successfully deleted (in a single VF or PF case) the
PCI tracker still keeps the now free device in the DB and therefore PCI
in Placement also keeps the RP. This keeps the non whitelisted device
available for allocations until the next nova-compute restart.
* The PCI in Placement logic is different between the case where
the last device is removed from an RP and the case where there
are other devices on the RP, some that can be removed and some that
cannot due to allocation.
Related-Bug: #2115905
Change-Id: Ib3febb77299da65ada24ed49849c04cbf3c41af1
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
Zuul