To help improve early detection of issues with newer noVNC releases the
nova-next job now deploys directly from source.
Depends-On: https://review.opendev.org/c/openstack/devstack/+/816736
Change-Id: Ic14d2b13cbf0369fc752d457d73d65488e6df3f9
Yoga testing runtime is updated now
- https://governance.openstack.org/tc/reference/runtimes/yoga.html
which needs to test py38 and py39. Unit tests update are
handled by the job template change in openstack-zuul-job and
this commit makes changes to fucntional job to run py39 as voting
and updating the metdata in setup file.
Change-Id: I314fd61f20f2c3551f6231d191b7dcaaefabd2b5
Apply the common nova irrelevant files filter for the new
tempest-integrated-compute-centos-8-stream job
Change-Id: I0bacb8884a75b5ae604383d73d60fc618123a8d3
The libvirt driver power on and hard reboot destroys the domain first
and unplugs the vifs then recreate the domain and replug the vifs.
However nova does not wait for the network-vif-plugged event before
unpause the domain. This can cause that the domain starts running and
requesting IP via DHCP before the networking backend finished plugging
the vifs.
So this patch adds a workaround config option to nova to wait for
network-vif-plugged events during hard reboot the same way as nova waits
for this event during new instance spawn.
This logic cannot be enabled unconditionally as not all neutron
networking backend sending plug time events to wait for. Also the logic
needs to be vnic_type dependent as ml2/ovs and the in tree sriov backend
often deployed together on the same compute. While ml2/ovs sends plug
time event the sriov backend does not send it reliably. So the
configuration is not just a boolean flag but a list of vnic_types
instead. This way the waiting for the plug time event for a vif that is
handled by ml2/ovs is possible while the instance has other vifs handled
by the sriov backend where no event can be expected.
Change-Id: Ie904d1513b5cf76d6d5f6877545e8eb378dd5499
Closes-Bug: #1946729
Bug #1912310 details an underlying QEMU live migration failure seen
during both volume backend and block migration based live migration
tests in the nova-live-migration job. The failure rate is getting high
enough now that we should mark these jobs as non-voting until it is
resolved.
Change-Id: Ifc211fadb3ca9c7c0a74d7dcd225bdb3f3008d26
Related-Bug: #1912310
As seen before in bug #1913451 the nova-lvm job creates large RAW
snapshots during each run due to the nature of using LVM storage for the
ephemeral instance disks.
Id425aa546f1a5973bae8be9c017782d18f0b4a47 recently landed capping the
per teneant image size total to 1000 MiB that is far too low for this
job given the RAW snapshots it's creating. This in turn resulted in
504 failures when n-cpu attempted to upload snapshots to g-api.
This change simply increases the per tenant limit to 10 GiB that should
be more than enough for all of the tests covered by the nova-lvm job.
Closes-Bug: #1938765
Change-Id: I824655387a10ac9b813c1b7b2399e25ed95f7fc3
The nova-tox-functional-py36 job was replaced with the current py38
version during Victoria by I1d6a2986fcb0435cfabdd104d202b65329909d2b.
However as clearly stated in both the Victoria and Xena runtime
reference documents python 3.6 remains supported through CentOS 8 and
later CentOS 8 stream.
This change reintroduces functional test coverage for py36 using a
CentOS 8 stream based job.
[1] https://governance.openstack.org/tc/reference/runtimes/victoria.html
[2] https://governance.openstack.org/tc/reference/runtimes/xena.html
Change-Id: I6ef77bd92f2595016a99d1953414d3f554f6b2eb
This currently runs in the 'check' pipeline, as part of the pep8 job,
which causes otherwise perfectly valid backports to report as failing
CI. There's no reason a stable core shouldn't be encouraged to review
these patches: we simply want to prevent them *merging* before their
parent(s). Resolve this conflict by moving the check to separate voting
job in the 'gate' pipeline as well as a non-voting job in the 'check'
pipeline to catch more obvious issues.
Change-Id: Id3e4452883f6a3cf44ff58b39ded82e882e28c23
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Bug #1931702 details soft lockups reported within the guest OS during
live migration with block migration and a volume attached. These lockups
then causing the request to detach the volume as part of the cleanup to
fail. For the time being we should skip these tests until the underlying
issue is resolved.
Related-Bug: #1931702
Change-Id: I7c1a647fb840fce98672a8429d554dd399cd13b7
The volume update or swap_volume API has long been a source of gate
failures within Nova. Most recently we've seen increased instability
when running the temptest.api.compute.admin.test_volume_swap tests as
part of the nova-next job as documented in bug #1929710.
This change temporarily removes the failing test from the nova-next job
while the underlying issue is identified lower in the virt stack.
Change-Id: Ib56a034fb08e309981d0b4553b8cee8d16b10152
Related-Bug: #1929710
This is no longer used with the removal of the legacy
nova-grenade-multinode job in I02b2b851a74f24816d2f782a66d94de81ee527b0.
dsvm-irrelevant-files is also renamed to nova-base-irrelevant-files and
now defined within the nova-live-migration job.
Change-Id: I67faa85618e2de1400d868299426b0ba8274c90e
If2608406776e0d5a06b726e65b55881e70562d18 dropped the single node
grenade job from the integrated-gate-compute template as it duplicates
the existing grenade-multinode job. However it doesn't remove the
remianing single node grenade job still present in the Nova project.
This change replaces the dsvm based nova-grenade-multinode job with the
zuulv3 native grenade-multinode based job.
Various legacy playbooks and hook scripts are also removed as they are
no longer used. Note that this does result in a loss of coverage for
ceph that should be replaced as soon as a zuulv3 native ceph based
multinode job is available.
Change-Id: I02b2b851a74f24816d2f782a66d94de81ee527b0
Tempest replaced the below rolevar for run-tempest role
- tempest_test_blacklist is replaced by tempest_test_exclude_list
- tempest_black_regex is replaced by tempest_exclude_regex
old name are still supported for compatiblity but we recommend
to switch to new one.
Change-Id: I4f2d01a4cf443f9c539158e77032cd3d8ce24ad7
Since Ib342e2d3c395830b4667a60de7e492d3b9de2f0a the nova gate has lacked
any libvirt live migration test coverage for ceph. This change
reintroduces this via a new zuulv3 native multinode live migration job
for ceph that includes additional instance evacuation coverage.
Depends-On: https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/711625
Change-Id: I6d0dbdcc84fe070e84d19d0c3d4306e6e0326e46
With the introduction of the libvirt-default-machine-type blueprint
operators are now able to change the default machine type used by an
existing environment more easily. This should hopefully allow more
deployments to switch to the modern q35 machine type, away from the
legacy pc machine type that is currently the default.
With this in mind this change aims to start testing the q35 machine type
as part of the nova-next job before we eventually change the default in
the future.
The following changes are made to the job to allow it to pass with q35:
- [libvirt]num_pcie_ports is increased to 24
This is required as more devices are now connected by default over PCIe.
- [compute-feature-enabled]ide_bus is disabled
The q35 machine type does not support an IDE bus so any tests using this
bus are now skipped.
Depends-On: https://review.opendev.org/c/openstack/devstack/+/779179
Depends-On: https://review.opendev.org/c/openstack/tempest/+/775630
blueprint: libvirt-default-machine-type
Change-Id: Iad1adbc23b31dd54a96299e7a8a4b622c15eed8d
As covered in the removed TODO this was to be done after bug #1771700
was resolved in Queens but instability in the job over the years stopped
this from ever happening.
With I7ad1d9820c48644bff7834560cdc7d5c13f7ed41 hopefully addressing the
only outstanding stability issue we can now finally mark the job as
voting again.
Related-Bug: #1771700
Change-Id: Ie9cba36ab602ab7c20c9a2c3b60e11e8506581ce
This is required as instance snapshots taken in this environment are
fully allocated RAW snapshots and consume considerably more space than
sparsely allocated RAW snapshots taken when Nova is using a file based
imagebackend.
We could look into sparsifying the resulting snapshots from the lvm
imagebackend but for the time being given the available space in our CI
hosts we can just extend space available to g-api via swift.
Closes-Bug: #1913451
Change-Id: I7ad1d9820c48644bff7834560cdc7d5c13f7ed41
As with the already listed encrypted volume tests this job specifically
blocks us from downloading non-raw images via Glance as part of these
tests so skip it.
Change-Id: Iaf6f6e0dbcb25561bf00e969e1964cd30e974e64
Closes-Bug: #1912607
This job tests the recently introduced direct download of rbd hosted
Glance images into a file based imagecache.
Depends-On: https://review.opendev.org/748212
Change-Id: I0933447e6caa0013f0b26dbf6532ff1976197e80
Zuul