Ansible 6 interprets the shebang line to know what version of python to
run a module under. Unfortunately, this is at odds with using the
shebang line normally on a unix system to execte the module as a normal
script. Devstack-gate uses the test-matrix library in both ways as an
Ansible module and as a normal script. To reconcile the differences we
drop the shebang entirely to force Ansible to use a default
interpretation, and on the script side we force users to run the script
with the python they want explicitly.
This is not ideal, but there isn't a better way to reconcile the
difference in Ansible 6 expectations and using things as a normal
script.
Change-Id: I9a331d508276d9abe72c789fd91fc77a4136c5ca
When devstack reverted the pip cap in [0], it was necessary to disable
the peakmem_tracker service as there was no easy way to make it work in
that setup. So we need to delete it from the test-matrix here, too.
We could decide to add it only for older stable/branches, but as ds-gate
is to be obsoleted anyway, I'm not convinced that that is worth the
effort.
[0] https://review.opendev.org/561597
Change-Id: I9dd57d3bdb56c64377efbdd55429bd075223c746
test-features.sh wasn't testing anything for subnodes
so this adds a subnode feature support matrix test for
grenade. It also highlights that the grenade config
is applied to all nodes regardless of role so a TODO
is added to test_matrix.py in case someone needs to make
that per-role, per-config service override support at
some point (hopefully that never really happens and all
jobs are moved to zuulv3 by that point).
Change-Id: I485d76c1db5c3a4363c3e26fea204cc7782887f3
Grenade only runs tempest smoke tests and there are no
cinder-backup service related smoke tests in the main
tempest repo so running the c-bak service on the primary
and subnode (in multinode jobs) is just a waste of resources
since it's not used in testing.
Similarly, etcd3 is really only interesting for cinder in
a multinode job but in grenade multinode jobs etcd3 is not
enabled on the subnode, so only the primary node cinder
services are configured to use etcd3, so again it's a waste
of resources.
There is a theory that bug 1844929 is failing primarily on
OVH nodes because they aggressively restrict iops so we're
running into swap issues [1]. Freeing up more resources on
the nodes used in grenade jobs might alleviate some of that
swap pressure.
To do this using the feature test matrix in devstack-gate
the test_matrix.py script has to be updated such that
services can be added/removed per config rather than per
feature because otherwise grenade says it wants cinder but
cannot remove cinder-specific services like c-bak.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010506.html
Change-Id: Ide146793053ae6b62f93a5af45c6130a21514e87
Related-Bug: #1844929
The cinder config is including the "cinder" devstack
service which would mean that anything removed explicitly,
like c-bak, is going to be trumped by the fact that 'cinder'
is in the enabled services list in a job.
This removes 'cinder' the service from cinder the config so
that cinder services have to be explicitly enabled/disabled
in the feature test matrix.
Change-Id: I857fbeba2af4a0f038fd2c2a19bb29c2767227a2
Ceilometer is not installed by default in legacy jobs using
devstack-gate so we shouldn't be enabling it by default. Anything
that cares about testing with ceilometer should be using a zuulv3
based job with the ceilometer devstack plugin and explicitly
enabling the service. So ceilometer is removed from the default
list of enabled services.
This also removes some now-dead nova services (n-obj, ha).
Change-Id: If8237c94be2b1db210f83bc9871792af9c5c868f
Promote "local hides exit status" (E042) to error and fix issues found
(this is inline with what we do in devstack).
Change-Id: Idd784af066db80bb67792da3dd0aa0ae4c8475db
Modify test-matrix.py so that is can be used as an ansible module.
Add a role in d-g that runs test matrix for the given branch,
role and features file.
Change-Id: Ie36ba0cd7cfcd450b75000a76a64d856f2a83eba
In the past we had gate configs where we didn't run the metadata service
because it wasn't as reliable as a config drive and it just wasted
memory. However, that isn't the case today, and almost all the jobs use
the metadata service. The exception here being ironic jobs, but running
the metadata service won't break things, it just will go unused. To
simplify the config and make the metadata api service config consistent
with the other nova services this commit makes sure that we are always
enabling the service in devstack.
Change-Id: I8ff08d61520ccf04e32dcd02f4cecc39dae823cb
The vast majority of jobs that d-g runs do not actually use or test
Horizon. Save job runtime by disabling Horizon by default which cuts
down on setup time. The depends on of this change explicitly enable's
Horizon in its integration job.
Change-Id: Ic9851f9e6fb3892c29ead1c64a77095e58d89630
Depends-On: Ib3fdab05bfa5f91678051db5643a976174f4797e
DevStack now has support for etcd3, let's turn it on for
all the jobs. Some more context in:
Ibbb430fb1dbf66942168e0cb52d990ab6a2eb8d7
Change-Id: I9b0209f7f327229ada9c5b677c5efbd57c9f759e
We experience unexplained behaviour lately in some gate jobs where
oom-killer is triggered while swap is not used. We suspect that it may
be because some process mlocked some pages in RAM. This service should
hopefully help us to understand if that's the case.
Change-Id: Ia5bbc3d5dc405af0417624b92816269775809e1a
There is no such service (as a separate entity) in devstack since at
least kilo (probably even earlier). Instead, neutron services are
controlled separately by q-* (legacy) or neutron-* (new devstack library
module).
Change-Id: I69a8866315acce1d192738873939d82bf397b918
Make placement API the default in ocata and later.
Depends-On: I04a655fbc58913b3d607400a7f677be299499142
Change-Id: Ibd760c642e3c1ffff2dd61be48e30530b0d24720
The service n-novnc is not enabled by default. This will enable it,
allowing tests associated with NoVNC to be executed. This also
specifies to install noVNC from packages instead of git cloning it
for gate jobs.
Change-Id: I09aed8de28f1ba2637382e870134ced38808df29
horizon is not really tested in grenade, so it's extra effort for no
real validation. We should not do this by default as it will shorten
the job length.
Depends-On: I2cb3c75bdd738a8e19796456f0aed14237ef755e
(enables horizon to be conditionally upgraded only if it exists)
Change-Id: Ifcf4dad0366a2763bb311f77ab63de1e5b3fafe7
We should transition to the DevStack fwaas plugin, similar
to what was done in c59dfacef8
Change-Id: Iadcee07e873fcb4f099ebccc2e33780e74438140
Related-Change: If6c6e032689392fecc8c24517666128c8c103a7b
Related-Change: Ic60cd1fa90c19dfac00be583e2ddc5633dbb68a3
Commit c59dfacef8 removed the q-vpn
service from being enabled in all neutron runs which is OK for liberty
since that project has it's own devstack plugin and job configs for
master, but it breaks stable/kilo.
So add the q-vpn service back in for kilo.
Related-Bug: #1473475
Change-Id: I69ea5b194fec520e1aa31eb0554cf83c447a5e18
There is a DevStack plugin for the neutron-vpnaas repo now, that
enables the q-vpn service. The repo has DSVM based (functional)
tests that use the new plugin and exercise the service.
We now want to remove q-vpn setup from the DevStack repo, and to
rely on the new plugin. To do that, however, we need to make sure
that DSVM tests (other than those in the neutron-vpnaas repo) do
not enable q-vpn, as it will not be set up during stacking (and
q-l3 will not be properly set up if q-vpn is enabled).
This patch, along with I3a4d7ecb25668eb499677d05bdb68b919592e53d
are attempting to remove q-vpn from the list of enabled services.
Change-Id: Idd5524ed0b602408be5a53830981a8ab974b390c
There is now a sahara specific tempest job. So sahara is no longer needed in
the default configuration of the integrated gate.
Change-Id: I7dc829fb0382c65b926b90f3a88843dd6495bb63
Depends-On: I1f89a4e6aa40250f5d036dcc98b59c0526e80995
There is now a heat specific tempest job. So Heat is no longer needed in
the default configuration of the integrated gate.
Change-Id: I70a20f36b333d7626751b099020f8f91c02cd147
Depends-On: I03fb778035926b6739394b64b370a245d31346c1
There is now a job that runs tempest with trove on top of the base
compute layer which runs on changes to trove. It is no longer
needed in the default configuration of the integrated gate.
Change-Id: Ibae66418e4c036713045dfa13a736145f9098665
Depends-On: Ie324c0d5a51bfe85f0fab871507b1f4331e8c357
It turns out there is actually no support for heat in grenade, so what
we're actually doing is starting heat on old, testing it, then not
actually upgrading heat, or testing it afterwards.
Testing heat on old isn't the purpose of this job, so we should drop
configuring that service. The normal heat tempest jobs should cover
that case anyway.
Change-Id: Iccc9135ef7abb73a414fa59ec7bc24513aa6e6e2
The advanced services migration has finished let's re-enable the
temporarily disabled testing and services.
This reverts commit 5358740468.
Change-Id: I10cdc1c6081aa2f66e924d65a8151e3bd118c7a2
As part of the migration of the advanced services out of the neutron repo
the testing in tempest needs to be disabled, otherwise the removal patch
in neutron will not be able to land. This is just a temporary workaround
to enable forward progress on the repo split, and should be reverted once
that is complete.
This patch passes the necessary configuration to devstack and tempest to
disable the advanced services from being started and also telling tempest
that the features aren't enabled. (which skips the tests) For setting the
enabled extensions in tempest this patch hard codes the extension list.
This is technically incorrect because this list isn't consistent between
branches, however since test-matrix.py doesn't support specifying
extensions yet, as a short-term temporary workaround it should be fine.
Related-Bug: #1400370
Co-Authored-By: Matthew Treinish <mtreinish@kortar.org>
Change-Id: I6044b27718de730286adcb69b2b1e1a2ab95e1fd
We EOLed, tagged, then deleted the stable/havana branches everywhere.
Clean havana out of devstack-gate as this config is no longer necessary.
Note this adds Juno specific test-features.sh tests because the havana
tests are no longer needed but we should continue to test that we
generate the proper feature lists for our stable branches.
Change-Id: Iea93ac03a9729cf6fe75a6410de4dec2c531f8d2
We need to be able to use grenade to upgrade services within a release
instead of upgrading services across releases. This will allow us to
test the nova baremetal to ironic upgrade path and the nova network to
neutron upgrade path.
To do this refactor the DEVSTACK_GATE_GRENADE* variables. Condense them
down to a single DEVSTACK_GATE_GRENADE variable that has more than just
0 and 1 binary states. This variable will state which type of grenade
test to do and handle that within devstack gate.
This change is backward and forward compatible for
DEVSTACK_GATE_GRENADE=1 and DEVSTACK_GATE_GRENADE_PARTIAL_NCPU=1 in
order to get this change through the gate without manual merging.
Change-Id: I4f102e27b422a5260cd0d5e40e00a5addf87911a
We are introducting Ceilometer upgrade process in Grenade:
https://review.openstack.org/#/c/94468/
This patch delete the "ceilometer service remove" when deploying
devstack-gate in a grenade environment.
Change-Id: Id96331d31b67ea8c669a1bb784dc6c1696d2c320
this enables heat in the grenade jobs. Because we need to explicitly
tell tempest what services to test, this doesn't actually test
heat (that will depend on additional grenade changes).
This is therefore a largely no-op change in normal runs which will
make it possible for the heat team to add real grenade support.
Change-Id: I6cfb2e4abf43abf91f96e85e82fcdd1fee3f9470
The previous change to fix test matrix generation did not include a
test. Add a test here so that this does not regress.
Change-Id: Ib267a435fa0f28e50a83437d96ad0ef321ba6f46
This adds a definition mechanism for the d-g feature matrix in
yaml, a python tool to process that into an ENABLED_SERVICES list
and a test script to verify that it works as expected.
The theory here is that we create configs (which match to d-g
DEVSTACK_GATE_ vars) that enable or disable "features". The
features then enable or disable "services" (and eventually
extensions).
An important part of this is the ability to rm-* content. That
means the neutron feature can rm-services: n-net. The hope is
this makes reviewing changes more straight forward, and also
makes it so if something goes wrong we don't run a job missing
services, because we don't need to make sure we add things in
the else clauses.
A follow up patch integrates this into d-g proper, but this
patch seemed easier to review on it's own.
Change-Id: Ib030f820073dd0b450b362fd721f9477778c04b0
Clark Boylan