Nowadays a significant amount of our test code coverage comes from
functional tests rather than just from unit tests.
Currently, we run unit tests under [testenv:cover] via .stestr.conf
and this just adds a run of the functional tests without API samples or
notification samples or database-only tests, for the sake of brevity.
In local testing this increases our Coverage Report from 87% to 89%
overall. And for the particular file I'm interested in,
nova/limit/utils.py, it increases coverage from 66% to 73%.
I'm doing this as a base for a bug fix in nova/limit/utils.py in the
next patch and with this change, I see coverage increase to 90%.
Change-Id: Iec0a9e38f3641e973894748ab2a14d1bd838e904
Signed-off-by: melanie witt <melwittt@gmail.com>
For graceful shutdown of compute service, it will have two RPC servers.
One RPC server is used for the new requests which will be stopped during
graceful shutdown and 2nd RPC server (listen on 'compute-alt' topic)
will be used to complete the in-progress operations.
We select the operations (case by case) and their RPC method to use
the 2nd PRC server so that they will not be interupted on shutdown
initiative and graceful shutdown time will keep 2nd RPC server active
for graceful_shutdown_timeout. A new method 'prepare_for_alt_rpcserver'
is added which will fallback to first RPC server if it detect the old
compute.
As this is upgrade impact, it bumps the compute/service version, adds
releasenotes for the same.
The list of operations who should use the 2nd RPC server will grow
evanutally and this commit moves the below operations to use the 2nd
RPC server:
* Live migration
- Live migration: It use 2nd RPC servers and will try to complete
the operation during shutdown.
- live_migration_force_complete does not need to use 2nd RPC server.
It is direct RPC request from API to compute and if that is
rejected during shutdown, it is fine and can be initiated again
once compute is up.
- live_migration_abort does not need to use 2nd RPC server. Ditto,
it is direct RPC request from API to compute. It cancel the queue
live migration but if migration is already started, then driver
cancel the migration. If it is rejected during shutdown because of
RPC is stopped, it is fine and can be initiated again.
* server external event
* Get server console
As graceful shutdown cannot be tested in tempest, this adds a new job
to test it. Currently it test the live migration operation which can
be extended to other operations who will use 2nd RPC server.
Partial implement blueprint nova-services-graceful-shutdown-part1
Change-Id: I4de3afbcfaefbed909a29a831ac18060c4a73246
Signed-off-by: Ghanshyam Maan <gmaan.os14@gmail.com>
Previous patches removed direct eventlet usage from nova-compute so
now we can run it with native threading as well. This patch documents
the possibility and switches both nova-compute processes to native
threading mode in the nova-next job.
Change-Id: I7bb29c627326892d1cf628bbf57efbaedda12f1a
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
The json format of policy files was deprecated long ago and is being
removed completely. Mention policy.yaml instead.
Change-Id: I9f6f11fd563d39a4fc1b940c67084292de7c56e3
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
This patch renames the nova-ovs-hybrid-plug Job to
nova-alt-configurations and ensures that all nova services are
running with eventlet even after some of the services switches to
native threading by default. This ensures we keep eventlet test
coverage in place.
Change-Id: Id2b70aa3870f2bf5a28c875a7564f84c012c9456
Signed-off-by: Balazs Gibizer <gibi@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>
Ubuntu Jammy is no longer supported since 2025.2 . Replace it by
Ubuntu Noble which is used in the other jobs.
Change-Id: I790fb06ede2c41cb80b3d2e8ff7faa7315c84016
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
The py312-threading tox target will run the currently working unit tests
with threading mode. We have an exclude list, those tests are
failing or hanging. Also the current test list might still have unstable
tests.
This also adds a non voting zuul job to run the new target.
Change-Id: Ibf41fede996fbf2ebaf6ae83df8cfde35acb2b7e
Signed-off-by: Balazs Gibizer <gibi@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>
The nova-next is blocked by missing kernel sources during compilation
disabling it until we find a solution. The result is not yet used by the
nova job so it is safe to disable.
Related-Bug: #2110545
Change-Id: Idb4be7d7537fe08f639b9c91b9f9bc261076884f
This patch adds a new console type, "spice-direct", which provides
the connection information required to talk the native SPICE protocol
directly to qemu on the hypervisor. This is intended to be fronted
by a proxy which will handle authentication separately.
A new microversion is introduced which adds the type "spice-direct"
to the existing "spice" protocol.
An example request:
POST /servers/<uuid>/remote-consoles
{
"remote_console": {
"protocol": "spice",
"type": "spice-direct"
}
}
An example response:
{
"remote_console": {
"protocol": "spice",
"type": "spice-direct",
"url": "http://localhost:13200/nova?token=XXX";
}
}
This token can then be used to lookup connection details for the
console using a request like this:
GET /os-console-auth-tokens/<consoletoken>
Which returns something like this:
{
"console": {
"instance_uuid": <uuid>,
"host": <hypervisor>,
"port": <a TCP port number>,
"tls_port": <another TCP port number>,
"internal_access_path": null
}
}
APIImpact
Change-Id: I1e701cbabc0e2c435685e31465159eec09e3b1a0
In centos/rhel 9 qemu supprot for the qxl model was removed
with the removal of spice support.
In ubuntu 24.04 qemu support for qxl and spice supprot
has now also been removed.
debian 12 bookworm still support spice in there qemu package.
When we updated the default video model to virtio for x86 we
left a config driven special case for spice to default to qxl
since that nolonger works on centos or ubuntu based distos that
default is not helpful so this change removes the special case
making virtio the default for x86 regardless of the console used.
This change also updates the nova-ovs-hybrid-plug to test with spice
so that we have at least one job using it. to enable that the job is
moved to debian.
Closes-Bug: #2097529
Change-Id: I265ad2ced3729bed41bf53c58dcebadb775ce1f7
The _heal_instance_info_cache periodic task predates
the introduction of the server external events API
which is now the canonical way to refresh the cache.
This change updates the default value of
``[compute]heal_instance_info_cache_interval``
to -1 disabling it by default.
The nova-ovs-hybrid-plug job is extended to test the
legacy configuration value and the config override is removed
from nova-next
Closes-Bug: #1996094
Related-Bug: #2089225
Change-Id: I33ac91bb4f3ead51af2f7005002d5eb5078540d9
This commit does the following changes in gate testing:
- Test tempest-integrated-compute-rbac-old-defaults (Test the
RBAC old defaults which are deprecated but still supported)
in periodic weekly pipeline instead of check/gate pipeline.
Reason: Old defaults are deprecated and it will be rare to
have any changes in those. These should be ok to run weekly
to know if anything is broken for old defaults.
- Remove tempest-integrated-compute-enforce-scope-new-defaults
This test the new defaults which are enabled by default and
tested in every job.
Reason: We kept this job for cinder because their new defaults
are not enabled by default. To test nova new defaults combination
with cinder new defaults, we have Tempest job running in tempest
gate (tempest-full-enforce-scope-new-defaults).
Change-Id: I3a1634ff71b39c722401dea8e77092228f9cc064
Neutron networking backends today are expected to work without
the periodic healing of the cache in Nova. Turn it off to gain
additional performance and in order to start testing this
setup in advance, before we are ready to change the default
value to it.
Change-Id: Ic90949cae840290dc376af7a7a3056babe2539f2
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Spotted while trying to ascertain if unified limits was being tested
anywhere.
Change-Id: Ib0f19a8153bdcc1222bc48ae518b3a9c9fde35a8
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
As per 2025.1 testing runtime[1], we need to test on Ubuntu
Noble (which will be taken care by tempest and devstack
patches to move base jobs to Noble (depends-On)) and at least single
job to run on Ubutnu Jammy (for smooth upgrade from previous
releases).
This commit keep rbac old default job continue running on Jammy
which can be moved to noble in next cycle.
Depends-On: https://review.opendev.org/c/openstack/tempest/+/932156
[1] https://governance.openstack.org/tc/reference/runtimes/2025.1.html
Change-Id: I99c0eb76d63a5902555f5527dbfdaf96c47a098f
Whitebox is a tempest plugin whose scope specifically includes peaking
behind the curtain. It is used for integration tests that cannot
perform their assertions based on just the REST API, which is the
limit in Tempest proper. Whitebox allows things like examining the
instance XML and querying the database. While it is not limited to
Nova in theory, in practice at the time of this commit, it only
contains compute-related tests.
This patch adds the basic integration job that whitebox uses in its
own CI to Nova's periodic weekly pipeline. Whitebox does a lof of
tests around CPU pinning, and therefore uses nodepool labels that
provide nested KVM support. For that reason, it's considered wasteful
to run it against every single Nova patch, so periodic is being
proposed here.
As a periodic job, its status will have to be a recurring item on the
Nova team meeting, similar to how the Placement periodic job is
treated.
In addition, we also add it to the experimental pipeline to allow for
manual trigger if deemed necessary on any particular patch.
Change-Id: I0e1b754d0b94194cf9baeb6e188036b03be727db
The nodepool provides different VMs as computes it can have 8 or 4 cpus.
So the reverted commit breaks the test runs that uses 4 cpu computes. We
need a smarter solution and until then we need to get back to a stable
CI.
This reverts commit aca63b66e5.
Change-Id: Id48c6143533fa97f0b79936a4551f0e19751db44
This change modifes the nova-live-migration job to define
[compute]cpu_shared_set to different ranges on the controller
and compute node. in ci we have 8 cpus so the controller is set
to 0-5 and the compute uses 2-7
6 cores with our default allocation ratio should be sufficent
for our current level of concurrancy. This change also adds
the remaining cores as cpu_dedicated_set, they will currently
be unused but are thre if we want to enable pinned cpu testing
in the future.
Change-Id: I0d8463cf584d6ac141a5e1cb492d17996db458e0
This change updates the nova-next nodeset
to use openstack-two-node-noble and revert to
using qemu without nested virt.
using nested virt was a tempory messure to mitigate the kernel
panics we were seeing related to volume detach while we also explored
using split kernel images. since then we have reverted the other
jobs back to using normal whole disk images and we have not
seen a marked uptic in kernel panics.
as such this change drop the use of nested virt since the other jobs
are not using it an updates the nodeset to move nova-next to test on
ubuneu 24.04 (noble) on python 3.12
Depends-On: https://review.opendev.org/c/openstack/devstack/+/922427
Change-Id: I5059ba3c519efb18947a8f3d24868ce1c9289e3d
The nova-ceph-multistore job is currently
not configured properly for the new image format
tests. This change skips them until we decided
how to fix this.
Change-Id: I3de7588ba224453c24beabf8a799c71677603ba7
Tempest currently defaults to disk_formats[0] for images it creates,
which is 'ami'. However, it's actually using a qcow2 disk image by
default, which means we're lying to glance when we create those.
Change-Id: I737e9aa51c268a387f1eed24cf717618d057d747
Latest Zuul drops the following warnings:
All regular expressions must conform to RE2 syntax, but an
expression using the deprecated Perl-style syntax has been detected.
Adjust the configuration to conform to RE2 syntax.
The RE2 syntax error is: invalid perl operator: (?!
This patch replaces the 'irrelevant-files' to 'files' with explicitly
listing the pattern which files should be the tests run against.
Change-Id: If287e800fb9ff428dbe6f9c4c046627f22afe3df
This change increases the swap in the emulation job form
1G to 8G
This change updates the default cirrors image form 0.5.2
to 0.5.3 to avoid know kernel bugs
this change reduces the tb_cache_size: to 128
The tempest concurrency is reduced to 4 to avoid
no valid host error in the resize tests
Change-Id: Ic1dde3d54f5ca12408ef53218773a27d55760705
Balazs Gibizer