From e0a00b3948839a449d0be47130cd771185a1443d Mon Sep 17 00:00:00 2001 From: Jan Fajerski Date: Mon, 13 Feb 2017 16:52:07 +0100 Subject: [PATCH] doc: update links to point to ceph/qa instead of ceph-qa-suite Also fix two broken links to install task and two typos. Signed-off-by: Jan Fajerski --- doc/dev/development-workflow.rst | 14 +++--- doc/dev/index.rst | 78 ++++++++++++++++---------------- 2 files changed, 46 insertions(+), 46 deletions(-) diff --git a/doc/dev/development-workflow.rst b/doc/dev/development-workflow.rst index 64aeed7e599..9374d8b6932 100644 --- a/doc/dev/development-workflow.rst +++ b/doc/dev/development-workflow.rst @@ -139,15 +139,15 @@ results are posted on `pulpito `_ and the The ``quality engineer`` is either a developer or a member of the QE team. There is at least one integration test suite per project: -* `rgw `_ suite -* `CephFS `_ suite -* `rados `_ suite -* `rbd `_ suite +* `rgw `_ suite +* `CephFS `_ suite +* `rados `_ suite +* `rbd `_ suite -and a many others such as +and many others such as -* `upgrade `_ suites -* `power-cyle `_ suite +* `upgrade `_ suites +* `power-cyle `_ suite * ... Preparing a new release diff --git a/doc/dev/index.rst b/doc/dev/index.rst index b0eaf0f908b..20e2c9ca07d 100644 --- a/doc/dev/index.rst +++ b/doc/dev/index.rst @@ -564,17 +564,17 @@ Integration (CI) team. When the tests complete, the result will be shown on GitHub in the pull request itself. You can (and should) also test your modifications before you open a PR. -Refer to the the `Testing`_ chapter for details. +Refer to the `Testing`_ chapter for details. Integration tests AKA ceph-qa-suite ----------------------------------- Since Ceph is a complex beast, it may also be necessary to test your fix to see how it behaves on real clusters running either on real or virtual -hardware. Tests designed for this purpose live in the `ceph-qa-suite -repository`_ and are run via the `teuthology framework`_. +hardware. Tests designed for this purpose live in the `ceph/qa +sub-directory`_ and are run via the `teuthology framework`_. -.. _`ceph-qa-suite repository`: https://github.com/ceph/ceph-qa-suite/ +.. _`ceph/qa sub-directory`: https://github.com/ceph/ceph/tree/master/qa/ .. _`teuthology repository`: https://github.com/ceph/teuthology .. _`teuthology framework`: https://github.com/ceph/teuthology @@ -681,7 +681,7 @@ Testing - integration tests When a test requires multiple machines, root access or lasts for a longer time (for example, to simulate a realistic Ceph deployment), it is deemed to be an integration test. Integration tests are organized into -"suites", which are defined in the `ceph-qa-suite repository`_ and run with +"suites", which are defined in the `ceph/qa sub-directory`_ and run with the ``teuthology-suite`` command. The ``teuthology-suite`` command is part of the `teuthology framework`_. @@ -697,7 +697,7 @@ multiple platforms using the same packages (RPM, DEB) that can be installed on any machine running those platforms. Teuthology has a `list of platforms that it supports -`_ (as +`_ (as of March 2016 the list consisted of "CentOS 7.2" and "Ubuntu 14.04"). It expects to be provided pre-built Ceph packages for these platforms. Teuthology deploys these platforms on machines (bare-metal or @@ -722,51 +722,51 @@ results are also reported on the `ceph-qa mailing list Suites inventory ---------------- -The ``suites`` directory of the `ceph-qa-suite repository`_ contains +The ``suites`` directory of the `ceph/qa sub-directory`_ contains all the integration tests, for all the Ceph components. -`ceph-deploy `_ +`ceph-deploy `_ install a Ceph cluster with ``ceph-deploy`` (`ceph-deploy man page`_) -`ceph-disk `_ +`ceph-disk `_ verify init scripts (upstart etc.) and udev integration with ``ceph-disk`` (`ceph-disk man page`_), with and without `dmcrypt `_ support. -`dummy `_ +`dummy `_ get a machine, do nothing and return success (commonly used to verify the integration testing infrastructure works as expected) -`fs `_ +`fs `_ test CephFS -`kcephfs `_ +`kcephfs `_ test the CephFS kernel module -`krbd `_ +`krbd `_ test the RBD kernel module -`powercycle `_ +`powercycle `_ verify the Ceph cluster behaves when machines are powered off and on again -`rados `_ +`rados `_ run Ceph clusters including OSDs and MONs, under various conditions of stress -`rbd `_ +`rbd `_ run RBD tests using actual Ceph clusters, with and without qemu -`rgw `_ +`rgw `_ run RGW tests using actual Ceph clusters -`smoke `_ +`smoke `_ run tests that exercise the Ceph API with an actual Ceph cluster -`teuthology `_ +`teuthology `_ verify that teuthology can run integration tests, with and without OpenStack -`upgrade `_ +`upgrade `_ for various versions of Ceph, verify that upgrades can happen without disrupting an ongoing workload @@ -828,7 +828,7 @@ How integration tests are defined --------------------------------- Integration tests are defined by yaml files found in the ``suites`` -subdirectory of the `ceph-qa-suite repository`_ and implemented by python +subdirectory of the `ceph/qa sub-directory`_ and implemented by python code found in the ``tasks`` subdirectory. Some tests ("standalone tests") are defined in a single yaml file, while other tests are defined by a directory tree containing yaml files that are combined, at runtime, into a @@ -841,7 +841,7 @@ Let us first examine a standalone test, or "singleton". Here is a commented example using the integration test `rados/singleton/all/admin-socket.yaml -`_ +`_ :: roles: @@ -873,19 +873,19 @@ id ``a`` (that is the ``mon.a`` in the list of roles) and two OSDs The body of the test is in the ``tasks`` array: each element is evaluated in order, causing the corresponding python file found in the ``tasks`` subdirectory of the `teuthology repository`_ or -`ceph-qa-suite repository`_ to be run. "Running" in this case means calling +`ceph/qa sub-directory`_ to be run. "Running" in this case means calling the ``task()`` function defined in that file. In this case, the `install -`_ +`_ task comes first. It installs the Ceph packages on each machine (as defined by the ``roles`` array). A full description of the ``install`` task is `found in the python file -`_ +`_ (search for "def task"). The ``ceph`` task, which is documented `here -`_ (again, +`_ (again, search for "def task"), starts OSDs and MONs (and possibly MDSs as well) as required by the ``roles`` array. In this example, it will start one MON (``mon.a``) and two OSDs (``osd.0`` and ``osd.1``), all on the same @@ -893,7 +893,7 @@ machine. Control moves to the next task when the Ceph cluster reaches ``HEALTH_OK`` state. The next task is ``admin_socket`` (`source code -`_). +`_). The parameter of the ``admin_socket`` task (and any other task) is a structure which is interpreted as documented in the task. In this example the parameter is a set of commands to be sent to the admin socket of @@ -911,7 +911,7 @@ Each test has a "test description", which is similar to a directory path, but not the same. In the case of a standalone test, like the one in `Reading a standalone test`_, the test description is identical to the relative path (starting from the ``suites/`` directory of the -`ceph-qa-suite repository`_) of the yaml file defining the test. +`ceph/qa sub-directory`_) of the yaml file defining the test. Much more commonly, tests are defined not by a single yaml file, but by a `directory tree of yaml files`. At runtime, the tree is walked and all yaml @@ -921,7 +921,7 @@ beginning of every test log. In these cases, the description of each test consists of the subdirectory under `suites/ -`_ containing the +`_ containing the yaml facets, followed by an expression in curly braces (``{}``) consisting of a list of yaml facets in order of concatenation. For instance the test description:: @@ -938,7 +938,7 @@ How are tests built from directories? As noted in the previous section, most tests are not defined in a single yaml file, but rather as a `combination` of files collected from a -directory tree within the ``suites/`` subdirectory of the `ceph-qa-suite repository`_. +directory tree within the ``suites/`` subdirectory of the `ceph/qa sub-directory`_. The set of all tests defined by a given subdirectory of ``suites/`` is called an "integration test suite", or a "teuthology suite". @@ -956,7 +956,7 @@ teuthology to construct a test matrix from yaml facets found in subdirectories below the directory containing the operator. For example, the `ceph-disk suite -`_ is +`_ is defined by the ``suites/ceph-disk/`` tree, which consists of the files and subdirectories in the following structure:: @@ -987,7 +987,7 @@ three standalone tests: (which would of course be wrong in this case). -Referring to the `ceph-qa-suite repository`_, you will notice that the +Referring to the `ceph/qa sub-directory`_, you will notice that the ``centos_7.0.yaml`` and ``ubuntu_14.04.yaml`` files in the ``suites/ceph-disk/basic/distros/`` directory are implemented as symlinks. By using symlinks instead of copying, a single file can appear in multiple @@ -1017,7 +1017,7 @@ Concatenation operator For even greater flexibility in sharing yaml files between suites, the special file plus (``+``) can be used to concatenate files within a directory. For instance, consider the `suites/rbd/thrash -`_ +`_ tree:: directory: rbd/thrash @@ -1071,7 +1071,7 @@ Filtering tests by their description When a few jobs fail and need to be run again, the ``--filter`` option can be used to select tests with a matching description. For instance, if the -``rados`` suite fails the `all/peer.yaml `_ test, the following will only run the tests that contain this file:: +``rados`` suite fails the `all/peer.yaml `_ test, the following will only run the tests that contain this file:: teuthology-suite --suite rados --filter all/peer.yaml @@ -1081,14 +1081,14 @@ option. Both ``--filter`` and ``--filter-out`` take a comma-separated list of strings (which means the comma character is implicitly forbidden in filenames found in the -`ceph-qa-suite repository`_). For instance:: +`ceph/qa sub-directory`_). For instance:: teuthology-suite --suite rados --filter all/peer.yaml,all/rest-api.yaml will run tests that contain either -`all/peer.yaml `_ +`all/peer.yaml `_ or -`all/rest-api.yaml `_ +`all/rest-api.yaml `_ Each string is looked up anywhere in the test description and has to be an exact match: they are not regular expressions. @@ -1098,10 +1098,10 @@ Reducing the number of tests The ``rados`` suite generates thousands of tests out of a few hundred files. For instance, all tests in the `rados/thrash suite -`_ +`_ run for ``xfs``, ``btrfs`` and ``ext4`` because they are combined (via special file ``%``) with the `fs directory -`_ +`_ All integration tests are required to be run before a Ceph release is published. When merely verifying whether a contribution can be merged without -- 2.39.5