Move the execution of build_and_run_instance and snapshot_instance to
one common long task executor. Originally snapshot ran
on the RPC pool, build_and_run_instance ran on the default pool.
Also each of these tasks had a separate concurrency limit enforced by a
semaphore.
After this patch each of these tasks use a common Executor. The size of
that executor and the way how we limit the concurrency differs in
eventlet and in native threading mode.
In eventlet mode we have one big Executor with "unlimit" size and
individual semaphores are used for each task type to enforce the
configured limits.
In threading mode we requests the admin to configure the 2 limits to the
same number, and we warn if not. We use that limit (or the max of the 2
limits) as the size of the long task Executor. As the limits are the
same we don't enforce individual limit any more. The executor size will
ensure the shared limit is kept. As the limit is shared a single
operation type can consume the whole limit.
Note that while live migration is a long-running task we cannot put it into
the same long_task_executor as build and snapshot as we need:
1. a very small limit of concurrent live migrations compared to
builds and snapshots
2. a way to cancel live migrations easily that are waiting due to the
limit
Change-Id: I88a6a593af8a5b518715e1245a76ee54752afe83
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
We also replace the use of typing.Union and add missing parameters and
returns types for Callable types.
Change-Id: I75ed4d1cc4d84515910a5bd315f8626135258148
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This changes the thread pool usage of the ComputeManager to go through
the concurrency mode aware util functions.
The concurrent live migration pool had a seemingly unlimited option
when configured with value 0, but in reality GreenThreadPool has a
default worker size of 1000. In reality it is almost never right to
have more than one live migration running concurrently. Also with
native threading having 1000 worker is just too costly. So we
decided to deprecate the value 0 and changed the implementation of
unlimited to mean 5 threads in native threading mode. We kept the 1000
greenthread in eventlet mode for backward compatibility.
The _sync_power_states periodic task also spawn tasks for each instance
to be synced. As it uses a shared data structure across these tasks
and the caller a lock is needed to avoid race conditions.
Also the default pool size is 1000 for these tasks in our configuration.
That would use a lot of memory on a busy host in native threading mode.
So we changed the default value from 1000 to 5.
Change-Id: I9567d5fabdf086b5d0493103d9f6bde4f66af387
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
This is a follow up for the release notes added in the commit
35207ee8b5 that changed the default mode
for the scheduler and the API services. At that time we missed to note
the upgrade impact of such change. So this patch extends the reno with
an upgrade note.
Change-Id: I280e7eb9c1da6eeaf50e96e8b19e296961f2651a
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
This has not been supported for some time.
Change-Id: Ic7073740deb0bf9670eebe77f0f8b0daca100a5c
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This patch switches the default concurrency mode to native threading
for the services that gained native threading support in Flamingo:
nova-scheduler, nova-api, and nova-metadata.
The OS_NOVA_DISABLE_EVENTLET_PATCHING env variable still can be used to
explicitly switch the concurrency mode to eventlet by
OS_NOVA_DISABLE_EVENTLET_PATCHING=false
We also ensure that the cover, docs, py3xx and functional tox targets
are still running with eventlet while py312-threading kept running
with native threading.
Change-Id: I86c7f31f19ca3345218171f0abfa8ddd4f8fc7ea
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
This is technical dead end and not something we're going to be able to
support long-term in pbr. We need to push users away from this. Doing so
highlights quite a few place where our docs need some work, particularly
in light of the recent removal of the eventlet servers.
Change-Id: I2ffaed710fac2612f5337aca5192af15eab46861
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
When using the weigher, we need to target the right cell context for the
existing instances in the host.
fill_metadata was also having an issue as we need to pass the dict value
from the updated dict by keying the instance uuid, not the whole dict of
updated instances.
Change-Id: I18260095ed263da4204f21de27f866568843804e
Closes-Bug: #2125935
Signed-off-by: Sylvain Bauza <sbauza@redhat.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>
This change fixes duplicate consecutive words from docs
as well as code.
Signed-off-by: Rajesh Tailor <ratailor@redhat.com>
Change-Id: I236ff41fccf831023b6f85840097148a30e84743
We also tackle the server security group and security group rules
controllers at the same time since they are so similar.
Change-Id: I7a039cdc172de59392215e9d6a9a24d03144cb85
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This is the last piece to allow users to request AMD SEV-ES for memory
encryption instead of AMD SEV. The CPU feature for memory encryption
can now be requested via the hw:mem_encryption_model flavor extra spec
or via the hw_mem_encryption_model image property.
Implements: blueprint amd-sev-es-libvirt-support
Change-Id: Ifc9b86ad7db887cc22b2cd252fe8adc81fdc29c6
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
This is prep work to support launching instances with AMD SEV-ES memory
encryption and adds the object field to select the CPU feature to
encrypt and protect memory data of instances.
Partially-Implements: blueprint amd-sev-es-libvirt-support
Change-Id: I71fde5438d4e22c9e2566f8a684c5a965a7f3dd3
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
This patch refines our logging, doc, and release notes about the native
threading mode of scheduler, api, and metadata services to ask for
pre-prod testing before enabled in production.
Change-Id: I04bbb3d7e4664a0cab8b30f4c34ee71774536353
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
This necessitates adding some missing return values for various mocks.
Combined, this brings our tests closer to reality and will be needed
once we add response schemas for these.
Change-Id: I1ff23082d257f98e4f63b84b287a3c374a62bf0b
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
These all belong in separate files. Make it so.
We also rename the volume_attachment schema file to volume_attachments,
to better link it to the actual API code, and tweak an error message to
fix some capitalization.
Change-Id: Iffefc263bbf19d18137207c0432c16fdb3c513f9
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
It turns out that nova-api and nova-metadata only depend on spawning
threads via scatter-gather. The scatter-gather already supports both
eventlet and threading mode so we can switch these services.
Our WSGI services (nova-api, nova-metadata) are not relying on
oslo.service to fork worker processes, but expect the web server to
handle that (uwsgi, apache mod_wsgi). This means we don't need to handle
any forking issues as no nova code runs before the fork.
Change-Id: Id3a339c605dfc730bdb7994c3ca45baafeb5af80
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
nova stopped supporting custom image properties many years
ago with the introduction of ovo.
when the image property show feature was added it incorrectly
filtered the instance_system_metadata table for the image prefix
but didnt restrict the responce to only standard image properties
This change adds that filtering and fixes minor issues with the
responce schema validation.
Related-Bug: #2098384
Change-Id: I11a8783b02f35b7dfc964bf49f1a8a0a2469abc3
Signed-off-by: Sean Mooney <work@seanmooney.info>
At the service startup nova need to initialize either the eventlet or
the threading backend of oslo.service. So this patch reuses the existing
logic behind OS_NOVA_DISABLE_EVENTLET_PATCHING.
When OS_NOVA_DISABLE_EVENTLET_PATCHING env variable is set to true the
service will select the threading backend otherwise the eventlet
backend.
Also to avoid later monkey patch calls to invalidated the selection if
the threading backend is selected then the monkey_patch code is
poisoned.
This patch also makes sure that oslo.messaging also initialized with the
matching executor backend.
As this is the last step to make nova-scheduler run in threading mode
this patch adds a release notes as well.
Change-Id: I6e2e6a43df78d23580b5e7402352a5036100ab36
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
Balazs Gibizer