In FIPS mode, using RSA keys for ssh is fine as long as SHA-1 is
not used for the signature algorithm. Unfortunately, the version
of cirros used in OpenStack CI does not have a version of dropbear
that supports SHA-2 signatures. So, any connections from a FIPS
enabled machine will fail as the cirros instance will only support
ssh-rsa (SHA-1 signatures).
To get around this, we add a new option to specify the key type
(validation.ssh_key_type). This will allow the addition of other
key types in future if needed.
Tempest now supports 'rsa' and 'ecdsa' key types.
We also add a fips job to the experimental queue to test the usage
of the new key type.
run-tempest is changed recently to add the new variables but
keep supporting the old ones too, for example:
tempest_black_regex, tempest_exclude_regex. and if both
old and new var are used in job definition (parent and child) then
new variables are picked. Because Tempest is branchless, zuul pick
the Tempest master playbooks/roles. That is why job running on stable
branch gate will pick the base job definition from Tempest master.
This way if any stable jobs which were defining the old var and using old
Tempest are broken if any of their parent job define the new var.
This commit pin the older run-tempest role for such stable branches.
from Tempest to DevStack as it tests DevStack side of things and
is useful for projects not using Tempest.
This is part 2 of 2.
The 1st part is DevStack-side, in Depends-On.
The script is left calling out to devstack because legacy (dsvm)
jobs rely on its presence.
We need to move 'gabbi_tempest_path' var to gabbi-tempest plugin jobs side
which is the only place it is being used. This var is specific to gabbi-tempest
not used for any other devstack-tempest jobs so defining it in devstack-tempest
base job is not the correct way. We might face issue like bug#1821072 again in
future which can end up blocking all gate jobs.
Below patch is moving this var to gabbi-tempest plugin.
The patch implements a new flag which will fail a job when any
resources were leaked - that can be used for verification that
tests are cleaning their resources after they are finished.
Devstack IPv6 base job 'devstack-IPv6' setup the IPv6 setting
to deploy the services to listen on IPv6 address.
Tempest 'devstack-tempest-ipv6' job derived from 'devstack-IPv6'
job adds the playbooks to run the tests.
As part of Train community goal 'Support IPv6-Only Deployments',
we will expand the 'devstack-tempest-ipv6' job to do
IPv6-only deployments verification.
This commit define the new roles of 'ipv6-only-deployments-verification'
which will be invoked as part of run phase of 'devstack-tempest-ipv6' job.
This role will do IPv6-only setting and deployments verification via
IPv6 verification script can be extended further to perform more checks
and via project specific test case. Those tests will run as part of project
specific child jobs.
The 'devstack-tempest-ipv6' job will be used as parent for project specific
IPv6-only job. Those child job can extend the project specific IPv6 verification
by defining new playebook for post-run. That way the base verification
done in 'devstack-tempest-ipv6' will still run in addition to project specific
verificaiton and tests run.
Verification structure will be:
- 'devstack-IPv6' deploy the service on IPv6
- 'devstack-tempest-ipv6' run will verify the IPv6-only setting and listen address
- Child jobs derived from 'devstack-tempest-ipv6' will run the IPv6 related test case or
any further IPv6 deployment verification.
This commit also adds the new job 'tempest-ipv6-only' which will run smoke
and ipv6 related tests present in Tempest. This job will be used to run
on 6 services (Nova, Neutron, Cinder, Keystone, Glance, Swift) deployed
The gabbi-tempest plugin uses an environment variable,
GABBI_TEMPEST_PATH, to identify directories in which to
find the gabbi  tests that will be run. This will be
used by a forthcoming zuul job  (hosted by the plugin)
that will automate gabbi-based service testing as described
in https://anticdent.org/gabbi-in-the-gate.html .
By setting the environment in the devstack-tempest playbook
we avoid needing to duplicate the playbook: we can use
it directly and have less risk of plays diverging. The
calling job (which doesn't allow the "environment" key)
sets a "var" which then sets the environment variable.
'tempest-scenario-multinode-lvm-multibackend' job used to run
- all scenario test including slow tests with lvm multi-backend setup
- live migration and migration tests
This commit make scenario job only run the scenario tests and exclude
migration and live migration tests out of it.
coverage of those tests are there in below jobs
- migration tests run as part of - 'neutron-tempest-multinode-full'
- live migration tests run as part of - 'nova-live-migration'
This helps to provide a generic job to run the scenario tests in parallel
including slow tests so that project like nova, cinder, neutron etc can
use this job ti run on their main pipeline.
is tempest job which run all scenario tests including slow tests
and migration tests as non voting job.
This commit migrate this job to tempest in-tree and later we can
modify this to zuulv3 native.
This is first step to make slow tests running on tempest as voting
and on project side also.
Currently there is a zuul-jobs role only used in this tempest job while
other jobs mostly use fetch-subunit-output role.
This changes tries to consolidate towards the most used role, to be able
to clean up zuul-jobs a bit.
stage-output is already invoked in the devstack job.
Rather than running the role again in Tempest post, extend the
list of files to be staged and extensions to be converted to txt.
Stage dir used to be /opt/stack but now devstack changed to
use ansible user dir as a stage dir (which is the default
value) so the override is not needed anymore.
Use the process-test-results role from zuul-jobs to generate the
subunit file and html report.
Setup the initial folder and play to run tempest.
This simply runs tempest full for now, with not support for config