This role is no longer used, and was a long ago replaced with tempest.
Right now, there are still some pieces of code that overwrite the
tempest testrepository.subunit with the pingtest, and so, the best
approach right now is ensure that the validate-simple is not being
called anywhere.
Change-Id: I5a2993fa93c08f842e936c80b0adf4f9fb5c3b0f
This will avoid all the tasks under tempest.yml to be executed, since
those are only required when run os_tempest.
Related-Bug: #1911696
Change-Id: If546256da1e79d63c102590884e73db49c59e7ab
Remove the logic to choose between validate-tempest and os_tempest.
From now, only os_tempest should be executed.
Also other changes in order to make it work properly:
* Disable stackviz for CentOS-7 based distros.
* In Queens, Auth_url ends with //v3 leading to auth issue, replacing
it with /v3 fixes the issue.
* Generate clouds.yaml only for overcloud.
* Setting the CURL_CA_BUNDLE in order to avoid invalid ssl certificate
errors
Related-Bug: #1891372
Co-authored-by: Chandan Kumar (raukadah) <chkumar@redhat.com>
Signed-off-by: Arx Cruz <arxcruz@redhat.com>
Depends-On: https://review.opendev.org/#/c/759830/
Change-Id: I96808cc1d6c01391775a5f38d6dc27b6cf214afa
Today we have two roles that run tempest, the first one that is
deprecated, validate-tempest, and the new one os_tempest.
The problem right now is that, in order to deprecate validate-tempest,
we need to ensure a smooth transition, and centralize everything in one
single playbook, is the best way to do it.
Furthermore, move old jobs running on centos 7 require some workarounds
to create the clouds.yaml file, that today would be harder.
This patch consolidate both os_tempest and validate-tempest in one
single playbook, and so, in the future, it's easier to just remove the
calls from validate-tempest in one single place rather than keep
searching for all the places we use it.
Change-Id: I9991f6c0ea51a3bf537bdcafd4220a5a025cc026
This is needed so os-tempest can also be used in addition to
validate-tempest role to run tempest when quickstart-extras-validate
playbook is used.
Also let's ensure virtualenv package is installed
when using os-tempest it can be absent when.
Change-Id: I44ab4eff686100966012118ccd9ac016d6c2ee54
Sometimes container or service does not start, and this
doesn't make the CI fail. Until now, the failed containers
are listed in the /var/log/extras/ tree, but it's not
checked on a regular basis.
This patch intends to make a hard failure in case either
a service or a container doesn't start as expected.
Co-Authored-By: Cédric Jeanneret <cjeanner@redhat.com>
Related-Bug: #1816523
Change-Id: I001e2f27d2b562bb0be87c8eaadcf3622e530498
Makes those files conformant with current linting rules and avoids
linting errors when we need to toch them again.
Previous doing "pre-commit run -a" uncovered these errors, now is no
longer reporting any other errors.
Change-Id: Ie4cf229c8f11c2b55b323eac23c89483b26d3781
dstat async task with poll=0 should fire and forget, with 1 sec
max limit for the shell to run and send its process to bg.
The change includes:
- Ignore errors on dstat play.
- Enable dstat only when tempest runs.
- Kills dstat before parsing logs and creating charts.
- Remove dstat_count.
Closes-Bug: #1760917
Change-Id: I9ee407e8274f3ab6c3aea3650a25cd31772a81d6
The tripleo-ui should always work out of the box.
Let's take a few basic steps to make sure that is
the case.
Change-Id: Ie320cf86a6d6d2bc810221e18f4be5e029c26df2
The workflow of
- configure_tempest is only defined twice and used in an important
condition but it is not really used anywhere; the variable which is
around is tempest_config. Use tempest_config properly, remove
then configure_tempest;
- execute validate-tempest also when tempest_config is true,
not only when run_tempest is true;
- execute the post-tempest task only if run_tempest is true;
no need to execute it if tempest was simply configured.
Change-Id: I84dce8ff4ebb1df2163b1de6279b35e564efea5b
This should allow easier composition of custom playbooks from bits and
pieces of quickstart-extras.yml. It will be especially useful when one
wants to reuse existing environment (e.g. deployed undercloud) and
perform additional automated actions on it. (The current solution has
been to use ansible tags, which has been quite error prone for me, and
i've sometimes ended up ruining my dev environment. Composing custom
playbooks is both safer and more straightforward to reason about.)
Depends-On: I513149a9de524dd3f017c583d06c35a165581715
Change-Id: Ie40da10fb96265340b243fff9b48fd18640de978
Ghanshyam Mann
yatinkarel