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
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.*
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
.. ===