176 lines
4.8 KiB
ReStructuredText
176 lines
4.8 KiB
ReStructuredText
:tocdepth: 1
|
|
|
|
.. _glossary:
|
|
|
|
========
|
|
Glossary
|
|
========
|
|
|
|
.. warning:: Unfortunately, our glossary is not full, but the Rally
|
|
team is working on improving it. If you cannot find a definition in
|
|
which you are interested, feel free to ping us via IRC
|
|
(#openstack-rally channel at Freenode) or via E-Mail
|
|
(openstack-discuss@lists.openstack.org with tag [Rally]).
|
|
|
|
.. contents::
|
|
:depth: 1
|
|
:local:
|
|
|
|
Common
|
|
======
|
|
|
|
Alembic
|
|
-------
|
|
|
|
A lightweight database migration tool which powers Rally migrations. Read more
|
|
at `Official Alembic documentation <http://alembic.readthedocs.io/en/latest/>`_
|
|
|
|
DB Migrations
|
|
-------------
|
|
|
|
Rally supports database schema and data transformations, which are also
|
|
known as migrations. This allows you to get your data up-to-date with
|
|
latest Rally version.
|
|
|
|
Rally
|
|
-----
|
|
|
|
A testing tool that automates and unifies multi-node OpenStack deployment
|
|
and cloud verification. It can be used as a basic tool
|
|
for an OpenStack CI/CD system that would continuously improve its SLA,
|
|
performance and stability.
|
|
|
|
Rally Config
|
|
------------
|
|
|
|
Rally behavior can be customized by editing its configuration file,
|
|
*rally.conf*, in `configparser
|
|
<https://docs.python.org/3.4/library/configparser.html>`_
|
|
format. While being installed, Rally generates a config with default
|
|
values from its `sample
|
|
<https://github.com/openstack/rally/blob/master/etc/rally/rally.conf.sample>`_.
|
|
When started, Rally searches for its config in
|
|
"<sys.prefix>/etc/rally/rally.conf", "~/.rally/rally.conf",
|
|
"/etc/rally/rally.conf"
|
|
|
|
Rally DB
|
|
--------
|
|
|
|
Rally uses a relational database as data storage. Several database backends
|
|
are supported: SQLite (default), PostgreSQL, and MySQL.
|
|
The database connection can be set via the configuration file option
|
|
*[database]/connection*.
|
|
|
|
Rally Plugin
|
|
------------
|
|
|
|
Most parts of Rally
|
|
`are pluggable <https://rally.readthedocs.io/en/latest/plugins/index.html>`_.
|
|
Scenarios, runners, contexts and even charts for HTML report are plugins.
|
|
It is easy to create your own plugin and use it. Read more at
|
|
`plugin reference <https://rally.readthedocs.io/en/latest/plugins/plugin_reference.html>`_.
|
|
|
|
Deployment
|
|
==========
|
|
|
|
Deployment
|
|
----------
|
|
|
|
A set of information about target environment (for example: URI and
|
|
authentication credentials) which is saved in the database. It is used
|
|
to define the target system for testing each time a task is started.
|
|
It has a "type" value which changes task behavior for the selected
|
|
target system; for example type "openstack" will enable OpenStack
|
|
authentication and services.
|
|
|
|
Task
|
|
====
|
|
|
|
Cleanup
|
|
-------
|
|
|
|
This is a specific context which removes all resources on target
|
|
system that were created by the current task. If some Rally-related
|
|
resources remain, please `file a bug
|
|
<https://bugs.launchpad.net/rally>`_ and attach the task file and a
|
|
list of remaining resources.
|
|
|
|
Context
|
|
-------
|
|
|
|
A type of plugin that can run some actions on the target environment
|
|
before the workloads start and after the last workload finishes. This
|
|
allows, for example, preparing the environment for workloads (e.g.,
|
|
create resources and change parameters) and restoring the environment
|
|
later. Each Context must implement ``setup()`` and ``cleanup()``
|
|
methods.
|
|
|
|
Input task
|
|
----------
|
|
|
|
A file that describes how to run a Rally Task. It can be in JSON or
|
|
YAML format. The *rally task start* command needs this file to run
|
|
the task. The input task is pre-processed by the `Jinja2
|
|
<http://jinja.pocoo.org/>`_ templating engine so it is very easy to
|
|
create repeated parts or calculate specific values at runtime. It is
|
|
also possible to pass values via CLI arguments, using the
|
|
*--task-args* or *--task-args-file* options.
|
|
|
|
Runner
|
|
------
|
|
|
|
This is a Rally plugin which decides how to run Workloads. For
|
|
example, they can be run serially in a single process, or using
|
|
concurrency.
|
|
|
|
Scenario
|
|
--------
|
|
|
|
Synonym for `Workload <#workload>`_
|
|
|
|
Service
|
|
-------
|
|
|
|
Abstraction layer that represents target environment API. For
|
|
example, this can be some OpenStack service. A Service provides API
|
|
versioning and action timings, simplifies API calls, and reduces code
|
|
duplication. It can be used in any Rally plugin.
|
|
|
|
SLA
|
|
---
|
|
|
|
Service-Level Agreement (Success Criteria).
|
|
Allows you to determine whether a subtask or workload is successful
|
|
by setting success criteria rules.
|
|
|
|
Subtask
|
|
-------
|
|
|
|
A part of a Task. There can be many subtasks in a single Task.
|
|
|
|
Task
|
|
----
|
|
|
|
An entity which includes all the necessary data for a test run, and
|
|
results of this run.
|
|
|
|
Workload
|
|
--------
|
|
|
|
An important part of Task: a plugin which is run by the runner. It is
|
|
usually run in separate thread. Workloads are grouped into Subtasks.
|
|
|
|
Verify
|
|
======
|
|
|
|
Rally can run different subunit-based testing tools against a target
|
|
environment, for example `tempest
|
|
<https://docs.openstack.org/tempest/latest/>`_ for OpenStack.
|
|
|
|
.. _glossary-verification:
|
|
|
|
Verification
|
|
------------
|
|
|
|
A result of running some third-party subunit-based testing tool.
|