RepoMirrors/ceph
1
0
Fork 0
mirror of https://github.com/ceph/ceph synced 2025-01-02 00:52:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

doc/dev: add "Deploy a cluster for manual testing" section

Browse Source 
http://tracker.ceph.com/issues/15218 Fixes: #15218

Signed-off-by: Nathan Cutler <ncutler@suse.com>
This commit is contained in:
Nathan Cutler 2016-03-20 12:32:36 +01:00
parent 22cac93ec7
commit 57c57548aa
1 changed files with 61 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
doc/dev/index.rst
View File

@ -674,11 +674,11 @@ results allows reviewers to verify that changes to the code base do not
cause regressions, or to analyze test failures when they do occur.
Every teuthology cluster, whether bare-metal or cloud-provisioned, has a
so-called "teuthology node" from which tests suites are triggered using the
so-called "teuthology machine" from which tests suites are triggered using the
`teuthology-suite`_ command.
A detailed and up-to-date description of each `teuthology-suite`_ option is
available by running the following command on the teuthology node::
available by running the following command on the teuthology machine::
$ teuthology-suite --help
@ -1068,7 +1068,7 @@ The last bit of output should look something like this::
What this means is that `ceph-workbench ceph-qa-suite`_ triggered the test
suite run. It does not mean that the suite run has completed. To monitor
progress of the run, check the Pulpito web interface URL periodically, or
if you are impatient, ssh to the teuthology node using the ssh command
if you are impatient, ssh to the teuthology machine using the ssh command
shown and do::
$ tail -f /var/log/teuthology.*
@ -1119,6 +1119,64 @@ there::
This will keep the teuthology machine, the logs and the packages-repository
instance but nuke everything else.
Deploy a cluster for manual testing
-----------------------------------
The `teuthology framework`_ and `ceph-workbench ceph-qa-suite`_ are
versatile tools that automatically provision Ceph clusters in the cloud and
run various tests on them in an automated fashion. This enables a single
engineer, in a matter of hours, to perform thousands of tests that would
keep dozens of human testers occupied for days or weeks if conducted
manually.
However, there are times when the automated tests do not cover a particular
scenario and manual testing is desired. It turns out that it is simple to
adapt a test to stop and wait after the Ceph installation phase, and the
engineer can then ssh into the running cluster.
This common use case is currently provided for by the following command::
ceph-workbench ceph-qa-suite --simultaneous-jobs 9 --verbose
--teuthology-git-url http://github.com/dachary/teuthology
--teuthology-branch openstack --ceph-qa-suite-git-url
http://github.com/dachary/ceph-qa-suite --suite-branch wip-ceph-disk
--ceph-git-url http://github.com/ceph/ceph --ceph jewel --suite
ceph-disk --filter ubuntu_14
This builds packages from the Ceph git repository and branch specified in
the ``--ceph-git-url`` and ``--ceph`` options, respectively, provisions VMs
in OpenStack, installs the packages, and deploys a Ceph cluster on them.
Then, instead of running automated tests, it stops and enters a wait loop.
The VMs (or "instances" in OpenStack terminology) created by
`ceph-workbench ceph-qa-suite`_ are named as follows:
``teuthology`` - the teuthology machine
``packages-repository`` - VM where packages are stored
``ceph-*`` - VM where packages are built
``target*`` - machines where tests are run
The VMs named ``target*`` are used by tests. If you are monitoring the
teuthology log for a given test, the hostnames of these target machines can
be found out by searching for the string ``Locked targets``::
2016-03-20T11:39:06.166 INFO:teuthology.task.internal:Locked targets:
target149202171058.teuthology: null
target149202171059.teuthology: null
The IP addresses of the target machines can be found by running
``openstack server list`` on the teuthology machine.
The whole process, which takes some time to complete, can be monitored as
described in `Run the dummy suite`_. Be patient.
Once the target machines are up and running and the test enters its wait
loop, the engineer can ssh into the target machines and do whatever manual
testing is required. Use the teuthology machine as jump host.
.. WIP
.. ===