This patch adds just the objects and notifications required to
support an extra spec to configure a sound device inside
the guest. This is useful for SPICE consoles using the native
protocol.
Change-Id: I2faeda0fd0fb9c8894d69558a1ccaab8da9f6a1b
Signed-off-by: Michael Still <mikal@stillhq.com>
As [1] switched over the implementation of spawn and spawn_n to the same
futurist Executor.submit we can now replace all spawn_n usage with spawn
and drop spawn_n from nova.utils.
[1]I3494660e1aaa1db46f9f08494cb5817ec7020cc5
Change-Id: I0027f119c0fbe8d5298307324eaf30c5e9e152d3
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
Nova uses nova.utils.spawn* to create new threads. This so far relied on
a GreenPool to provide GreenThreads. We changes this pool to a
futurist.GreenThreadPoolExecutor to have an interface where the
implementation can be swapped out to futurist.ThreadPoolExecutor to get
native threads instead.
This is an interface change on utils.spawn as it will return
futurist.Future instead of GreenThread. So couple of fixes needed across
nova to use:
* .result() instead of .wait()
* .add_done_callback() instead of .link(). Here we needed to change the
usage as the new callback does not forward args, so we rely on
closures instead.
This is also an interface and a behavior change for utils.spawn_n as it
now calls utils.spawn internally. This means that top of the above
detailed interface change there is behavior change for spawn_n.
The spawn creates GreenThread a wrapper around greenlet while spawn_n
created only the underlying greenlet. The greenlet cannot be managed
the same way as a more intelligent GreenThread, including the return
value but not limited to it, e.g. the whole cancellation mechanism
is missing from greenlet too. After this patch spawn_n will also use
GreenThread instead of naked greenlet. We consider the resulting small
performance change negligible.
Also the way we implement SpawnIsSynchronousFixture in our test is
adapted along with other test fixture adaptation to call / mock the
right functions.
Change-Id: I3494660e1aaa1db46f9f08494cb5817ec7020cc5
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
* Add a note explaining presence of xvpvnc console type
* Make 'url' mandatory in create response
* Remove unnecessary description fields: we will populate these later
* De-deuplcate request body schemas
* Re-add references to the rdp console to the api-ref
Change-Id: I5555b8cf7a83fad689e98522850b5550b49566ed
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The RPC handler build_and_run_instance has a normal set of error handler
decorators but that call immediately spawns a separate thread and does not
wait for its result so it cannot get any exceptions. Therefore the error
handling should happen inside the thread. And it does. Mostly.
The _locked_do_build_and_run_instance is the function run by the thread
and it calls _do_build_and_run_instance. The _do_build_and_run_instance
has `except Exception` handling dropping the active exception and returning
an error value instead. So most of the exceptions are handled by
_do_build_and_run_instance without going through any of the error
decorators.
Whatever exception still bubbles up from _do_build_and_run_instance
are going through the error handling decorators top of
_do_build_and_run_instance.
The only source of exception outside of _do_build_and_run_instance but
within _locked_do_build_and_run_instance is
delete_allocation_for_instance. Exception from that call does not
go though any error handling decorators.
These error decorators has multiple tasks:
* wrap_exception calls _emit_legacy_exception_notification and
_emit_versioned_exception_notification so sending error
notifications
* reverts_task_state sets instance.task_state to None
* wrap_instance_fault records InstanceFault object to the DB
So there are two cases when error happens but the decorators are not
called:
* _do_build_and_run_instance catches the exception, does its own error
handling and cleanup and then returns an error value. The task state
revert and the InstanceFault creation is replicated to the individual
cleanup sections here.
Note that notification sending is not missing either as that is
handled by the _build_and_run_instance called from
_do_build_and_run_instance.
* delete_allocation_for_instance raises when called from
_locked_do_build_and_run_instance. We reach this call if
_do_build_and_run_instance failed already and did its own cleanup. So
again task state are already reset and InstanceFault already recorded
for the original fault and notification already sent.
So the only changes here is to add a note to build_and_run_instance so
that the real error handling are deeper in the stack so that readers will
not think error handling happen on top of the call stack.
There was two unit test cases that partially relied on the wrong
assumption that exceptions propagate to build_and_run_instance.
They could make that wrong assumption because the
SpawnIsSynchronousFixture simulates the GreenThread interface wrongly.
The goal of that fixture is to make any spawn (and spawn_n) call
synchronous meaning the function passed in is executed right away before
spawn returns. That is OK. But the fixture forgot that if the function
raises then such exception is now raised by spawn. Such a thing never
happens with a normal spawn. The exception (and the function return
value) only propagated when GreenThread.wait() is called.
So this patch fixes the fixture and corrects the two unit tests as well.
Change-Id: I440fff6663d0663fb1630dd096f352403982aa37
Due to a bug in python3.13 [1] the following code will leads to an
emptied dict by the GC even though we hold a reference to the dict.
import gc
class A:
def __init__(self, client):
self.__dict__ = client.__dict__
self.client = client
class B:
def __init__(self):
self.test_attr = "foo"
a = A(B())
print(a.__dict__)
print(a.client.__dict__)
gc.collect()
print("## After gc.collect()")
print(a.__dict__)
print(a.client.__dict__)
# Output with Python 13
{'test_attr': 'foo', 'client': <__main__.B object at 0x73ea355a8590>}
{'test_attr': 'foo', 'client': <__main__.B object at 0x73ea355a8590>}
## After gc.collect()
{'test_attr': 'foo', 'client': <__main__.B object at 0x73ea355a8590>}
{}
# Output with Python 12
{'test_attr': 'foo', 'client': <__main__.B object at 0x79c86f355400>}
{'test_attr': 'foo', 'client': <__main__.B object at 0x79c86f355400>}
## After gc.collect()
{'test_attr': 'foo', 'client': <__main__.B object at 0x79c86f355400>}
{'test_attr': 'foo', 'client': <__main__.B object at 0x79c86f355400>
Our neutron client has this kind of code and therefore failing in
python3.13. This patch adds __getattr__ instead of trying to hold a
direct reference to the __dict__. This seems to work around the
problem.
Co-Authored-By: Johannes Kulik <johannes.kulik@sap.com>
[1] https://github.com/python/cpython/issues/130327
Closes-Bug: #2103413
Change-Id: I87c9fbb9331135674232c6e77d700966a938b0ac
This rewrites the core logic of scatter-gather to use
the futurist lib that provides a consistent API to use either Green
or native ThreadPoolExecutor. This way the scatter-gather code
can be made independent from the actual concurrency backend.
In this change we also create a separate executor for the scatter-gather
calls to better control it.
A new config option [default]cell_worker_thread_pool_size is added
to define the number of threads in this ThreadPoolExecutor. For the
GreenThreadPoolExecutor case this config is ignored as only real
threads are expensive, green threads doesn't.
As oslo.sevice use os.fork(), and fork copies the parent process state
to the children processes we need to make sure that the children
processes get a proper, fresh executor state, so we destroy the
executor just before the fork.
The fixtures.SynchronousThreadPoolExecutorFixture is deleted. It was
globally mocking futurist.GreenThreadPoolExecutor which would now
mocking more than what we want. There was only one usage of it in the
ComputeManager testing where it is replaced with a direct change of the
manager internal executor in the test setup to get the same, but
localized, result.
Note that testing the threading mode is done in nova-next job
in I36c68740fae3e3a9bd3286a1b66d86fd3341aff5, pool statistics
reporting will be added by Id4244f5ae0fd49c99af2898789cdd510859e150d,
and documentation about our threading tunables are in
I003177de3a9f69c71c19eb8eaa7232785e03e669.
Change-Id: Ibff6c73ad9af911a42204e53fee31ed5537c829d
For each lifecycle operation nova re-load, parses, and validates the
[pci]alias config option. This is wasteful. So this patch adds
functools.cache decorator on the function used to do this work.
Change-Id: If2ffb25430749a22c923c0938221833e7b883873
Both nova-api and nova-compute depends on the [pci]alias configuration.
These services loaded and validated the config lazily when it was
needed. This can late and hard to troubleshoot failures during instance
lifecycle operations due to simple config errors.
So this patch adds an early load of this config to nova-api and
nova-compute.
Related-Bug: #2102038
Related-Bug: #2111440
Change-Id: I5d5dc912ca24979067984c7cb53ceaded7daf236
Either the vendor_id and product_id needs to be set or the
resource_class needs to be set in each alias. This is now validated when
the alias is parsed to avoid late failure during placement
allocation_candidates query.
Closes-Bug: #2111440
Change-Id: I7fd43b3d6faac8c4098b0983e8adc596414823a1
Document and the limitation of the PCI in Placement feature that it
does not support [pci]alias configuration where the name of the alias is
repeated. E.g.
[pci]
alias = { "name": "vf1", "product_id":"10ca", "vendor_id":"8086", "device_type":"type-VF"}
alias = { "name": "vf1", "product_id":"f000", "vendor_id":"8086", "device_type":"type-VF"}
This would mean the alias vf1 can be fulfilled from devices with product
id 10ca OR f000. However this OR relationship cannot be encoded to a
single Placement allocation query as Placement does not support
requesting alternative resource classes for a request[2].
This limitation was encoded in the original PCI in Placement
implementation[1] but we missed to mention it in the doc.
This is now fixed.
[1]https://github.com/openstack/nova/blob/0d484ce37d86e989c8abdf57aec5e334f68206ef/nova/objects/request_spec.py#L504-L528
[2]https://docs.openstack.org/api-ref/placement/#list-allocation-candidates
Related-Bug: #2102038
Change-Id: I9dd78b1498f870a4e4c3f26c23d42d105aec0350
PCI in Placement never supported PCI aliases with multiple specs, i.e.
when an alias name is used in multiple alias definitions. The code
raised ValueError late and without a proper error message. Now
PciInvalidAlias with a descriptive message is raised instead.
Closes-Bug: #2102038
Change-Id: Id1407a37dc5ddad22d8dbf7d589ed998ffc2804e
* Address an off-by-one error: the cpu_info field was modified in v2.28,
not v2.27,
* Correct the api-ref to indicate that the 'servers' field is not
actually required and will be missing if '?with_servers=false', while
the 'name' and 'uuid' fields of servers entries *are* required.
* Clarify a comment about the above in the schemas.
* Uncouple the '_hypervisor_response' and '_hypervisor_detail_response'
helper schemas. The minor increase in lines of code is worth it for
the decrease in complexity.
* Add the 'host_ip', 'hypervisor_type', and 'hypervisor_version' fields
to the list of required fields for "detail"-style responses (show and
detailed list).
* Make the 'current_workload', 'disk_available_least', 'free_disk_gb',
'free_ram_mb', 'host_ip' and 'running_vms' fields of the hypervisor
"detail"-style responses nullable, and the 'current_workload',
'disk_available_least', 'free_disk_gb', 'free_ram_mb' and
'running_vms' fields of the deprecated statistics API nullable.
Change-Id: Ibe55b44e65fe17141c63cceae8a003816ffe4f23
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The libvirt driver now automatically enables autodeflate and
freePageReporting attributes for virtio memory balloon devices.
The autodeflate feature allows the QEMU virtio memory balloon
to release memory before the Out of Memory killer activates.
The freePageReporting feature enables returning unused pages
back to the hypervisor for use by other guests or processes,
improving overall memory efficiency on compute hosts.
These features are always enabled when a memballoon device is
configured, requiring no additional configuration from operators.
implements: blueprint automatic-memballoon-freeing
Generated-By: claude-code
Change-Id: If47a6d38cd311b08b78acffb307a99a7a2a080a1
Signed-off-by: Sean Mooney <work@seanmooney.info>
Michael Still