Full support for CentOS8Stream in devstack didn't land until
I39ccefbd06f46adf5077f8d8001f37d3b190f040 fixed is_fedora to include the
newly introduced name.
As such the recently introduced
tempest-integrated-compute-centos-8-stream job within tempest that forms
part of the integrated-gate-compute template needs to be restricted to
branches >= stable/wallaby.
As set out in the governance repo for Xena CentOS 8 stream with py36 is
a supported platform and runtime for the release:
As a result the Nova team want to run CentOS 8 stream based jobs within
the integrated-gate-compute template.
An additional tempest-full-py3-centos-8-stream job is added to Tempest's
check and gate queues to ensure coverage here.
Both jobs are given additional swap to workaround bug #1949606, a
behaviour change in QEMU >= 5.0.0 when using [libvirt]virt_type=qemu
that causes additional memory to be consumed by each running instance.
This workaround of additional swap will be removed in the future once
Nova is able to workaround this itself through a new libvirt domain
Now we have stable/xena branch ready for devstack
and so does for all service projects.
This commit adds the Tempest testing for stable/xena
by adding new jobs running on stable/xena version of
This reverts commit 0976ae4ee2. That
commit introduced a skip of MinBwAllocationPlacementTest tests if no
bandwidth allocation is possible to avoid failing these tests in OVN
jobs. However that is a wrong solutions as it would skip the test also
in OVS jobs if we regress the bandwidth inventory reporting in neutron
(or regress allocation candidate handling in placement).
A better fix is not to enable the tempest test flag on OVN jobs:
The existing tests already skipped if this is not configured.
This also means that the generic tempest-* job definitions should not
configure the above flag as those tempest jobs will run by default with
OVN. So they are cleaned up along with the OVS specific neutron configuration.
This means that jobs that was inherit from tempest-multinode-full-py3
and tempest-full-py3 and reconfigre the job to run with OVS instead of
the default OVN needs to change to configure the OVS specific network
config and enable the qos tests. This will be done in project specific
The stable tempest jobs are OK as they are still running with OVS by
API microversions are inhertied in nature from features points
of view, means higher microversion will have all the features/
changes done in lower microversion.
In Tempest we write the microversion tests by capping
the min and max microversion so that they can request
the API with correct microversion.
But for non microversion tests we do not test if they are
run-able for all the configured microversion in Tempest config
file. To test it at some extend this commit adds a experimental
job to run the API tests (compute and volume) with 'latest'
microversion to know if that run successfully or need modification.
This job is experimental as now as I expect lot of test failure
with the 'latest' microversion and as we keep fixing those and all
the tests pass then we can move it to voting job in check/gate pipeline.
Currently tempest-ipv6-only job run on all the files change
present in /tools dir which is not required. For example
when we update the tempest plugin sanity scripts present in
/tools dir then this job run which is unneccessary.
Optimizing the tools dir file as per related job required to run.
Derive the job from the py3 version of the multinode base job,
otherwise several definitions are lost.
The more visible symption of this issue is the wrong usage of
USE_PYTHON3=False when the job is used on stable/ussuri.
Swift is ready on py3 since stable/ussuri and we enabled
it in tempest-full-py3 job for stable/ussuri onwards.
This commit does the same for tempest-slow-py3 job also so that
we can run swift slow test in this job.
We have many job definition version for stable and master
gate and those are in same file integrated-gate.yaml. This
create confusion while modifying these jobs for master and
can end up modifying stable version.
Keeping all stable job definition in stable-jobs.yaml will help
us to accidentally modifying the stable jobs definition.
When we created the separate definition for tempest-full-py3 job
for swift enable on ussuri onwards, we missed to add the
few configutation like horizon, networking config due to rebase
This commit re-add all those configuration back to job version
of ussuri onwards.
This issue is found when we saw horizon dashbaord test is skipped
in tempest-full-py3 master gate.
Tempest use stestr to run the tests, adding
a experimental and periodic job to run Tempest
with stestr master will help to detect any
breaking change in advance.
Now we have stable/wallaby branch ready for devstack
and so does for all service projects.
This commit adds the Tempest testing for stable/wallaby
by adding new jobs running on stable/wallaby version of
Neutron recently enhanced CIDR overlap checks for all the subnets
attached to router including external . This breaks tempest
scenario ipv6 tests which is fixed in tempest by the following
commit . However the fix mentioned in  cannot be ported
back to tempest 23.0.0 as rocky is in EM stage.
To fix this, the public IPv6 network CIDR is changed to use
different subnet on the tempest-slow job.
swift was disabled in tempest-full-py3 as
it was not ready on python3. But since ussuri
or train swift run fine on py3 and we have
tempest storage integrated py3 job also running on
This commit enable swift for ussuri onwards.
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.
devstack-tempest and devstack-tempest-ipv6 jobs
are base jobs and other Tempest job like tempest-full-py3
or Tempest-ipv6-only are derived from those base job so running
tempest jobs are enough.
We do not need to run base jobs as such.
Devstack depends-on patch enable the way to install the things
in parallel, let's try it in tempest-full-parallel job which
run all the scenario tests in parallel with API tests.
This can help to check the stability of devstack parallel logic
as well as to see how much improvement it add in runtime. If
tempest-full-parallel job run faster then it will be
bigger step to run back the scneario tests in parallel.
As disscussed in Wallaby PTG, QA and Horizon team
decided to move the horizon dashboard test from tempest-horizon
to Tempest. As next step, we can remove the tempest-horizon
plugin which will ease the maintaince of horizon tempest test.
The grenade multinode job that nova runs is a superset of the base
grenade job. There is really no reason for us to run both, and doing
so consumes a lot of resources for no real gain.
test_qos_min_bw_allocation_basic usually execute in less than 60 secs,
so let's remove slow tag from it.
This patch removes the following config options from tempest-slow job:
* bridge_mappings and resource_provider_bandwidths from
* qos_placement_physnet from network-feature-enabled in tempest.conf
Current .zuul.yaml file has 36 jobs definition and
it is growing more which makes it hard to read and
This commit move the jobs definitions to zuul.d directory to
different yaml files:
- base.yaml includes base jobs definition
- integrated-gate.yaml includes integrated jobs to be
used in other openstack projects too.
- stable-jobs.yaml includes all stable jobs
- tempest-specific.yaml includes jobs supposed to run on Tempest
- project.yaml includes different pipelines (check, gate etc) definition