Verifier Plugin is a compatibility layer between Rally and the specific tool (such as Tempest) which runs tests. It implements features like installation, configuration, upgrades, running, etc in terms of the tool. It is a driver in other words. It is a pluggable entity, which means that you can easily add support for whatever tool you want (see HowTo add support for new tool page for more information). Even more, you can deliver such plugin separately from Rally itself, but we firmly recommend to push a change to Rally upstream (see Contribute to Rally guide), so Rally core-team will able to review it and help to improve.
Verifier is an instance of the Verifier Plugin. It is an installed tool. For example, “Tempest” is a set of functional tests, it is Verifier Plugin (we have a plugin for it). Installed Tempest 12.0 from https://github.com/openstack/tempest in a virtual environment is the verifier.
Verifier is not aligned to any particular deployment like it was in the past, you can use one verifier for testing unlimited number of deployments (each deployment will have separate configuration files for the tool).
Verifier & Verifier Plugin are the main entities which Verification component operates with. Another one is the verifications results.
All verifiers can be in next statuses:
- init - Initial state. It appears while you call
rally verify create-verifiercommand and installation step is not yet started.
- installing - Installation of the verifier is not a quick task. It is about cloning tool, checking packages or installing virtual environments with all required packages. This state indicates that this step is in the process.
- installed - It should be one of your favourite states. It means that everything is ok and you can start verifying your cloud.
- updating - This state identifies the process of updating verifier (version, source, packages, etc.).
- extending - The process of extending a verifier by its plugins.
- failed - Something went wrong while installation.
- init - Initial state. It appears instantly after calling
rally verify startcommand before the actual run of verifier’s tool.
- running - Identifies the process of execution tool.
- finished- Verification is finished without errors and failures.
- failed - Verification is finished, but there are some failed tests.
- crashed - Unexpected error had happened while running verification.
Out of the box¶
You can execute command
rally verify list-plugins locally to check
available verifiers in your environment.
Cut down from Global Plugins Reference page:
Quote from official documentation:This is a set of integration tests to be run against a live OpenStack cluster. Tempest has batteries of tests for OpenStack API validation, Scenarios, and other specific tests useful in validating an OpenStack deployment.
Rally supports features listed below:
- cloning Tempest: repository and version can be specified
- installation: system-wide with checking existence of required packages or in virtual environment
- configuration: options are discovered via OpenStack API, but you can override them if you need
- running: pre-creating all required resources(i.e images, tenants, etc), prepare arguments, launching Tempest, live-progress output
- results: all verifications are stored in db, you can built reports, compare verification at whatever you want time.
Appeared in Rally 0.8.0 (actually, it appeared long time ago with first revision of Verification Component, but 0.8.0 is mentioned since it is first release after Verification Component redesign)
- concurrency: Number of processes to be used for launching tests. In case of 0 value, number of processes will be equal to number of CPU cores.
- load_list: a list of tests to launch.
- pattern: a regular expression of tests to launch.
- set: Name of predefined set of tests. Known names: full, smoke, baremetal, clustering, compute, database, data_processing, identity, image, messaging, network, object_storage, orchestration, telemetry, volume, scenario
- skip_list: a list of tests to skip (actually, it is a dict where keys are names of tests, values are reasons).
- xfail_list: a list of tests that are expected to fail (actually, it is a dict where keys are names of tests, values are reasons).
- system_wide: Whether or not to use the system-wide environment for verifier instead of a virtual environment. Defaults to False.
- source: Path or URL to the repo to clone verifier from. Defaults to https://opendev.org/openstack/tempest
- version: Branch, tag or commit ID to checkout before verifier installation. Defaults to ‘master’.
Nothing here yet.