]> git.proxmox.com Git - ceph.git/blob - ceph/doc/dev/developer_guide/testing_integration_tests/tests-integration-testing-teuthology-workflow.rst
update ceph source to reef 18.1.2
[ceph.git] / ceph / doc / dev / developer_guide / testing_integration_tests / tests-integration-testing-teuthology-workflow.rst
1 .. _tests-integration-testing-teuthology-workflow:
2
3 Integration Tests using Teuthology Workflow
4 ===========================================
5
6 Scheduling Test Run
7 -------------------
8
9 Getting binaries
10 ****************
11
12 Ceph binaries must be built for your branch before you can use teuthology to run integration tests on them. Follow these steps to build the Ceph binaries:
13
14 #. Push the branch to the `ceph-ci`_ repository. This triggers the process of
15 building the binaries on the Jenkins CI.
16
17 #. To ensure that the build process has been initiated, confirm that the branch
18 name has appeared in the list of "Latest Builds Available" at `Shaman`_.
19 Soon after you start the build process, the testing infrastructure adds
20 other, similarly-named builds to the list of "Latest Builds Available".
21 The names of these new builds will contain the names of various Linux
22 distributions of Linux and will be used to test your build against those
23 Linux distributions.
24
25 #. Wait for the packages to be built and uploaded to `Chacra`_, and wait for
26 the repositories offering the packages to be created. The entries for the
27 branch names in the list of "Latest Builds Available" on `Shaman`_ will turn
28 green to indicate that the packages have been uploaded to `Chacra`_ and to
29 indicate that their repositories have been created. Wait until each entry
30 is coloured green. This usually takes between two and three hours depending
31 on the availability of the machines.
32
33 The Chacra URL for a particular build can be queried from `the Chacra site`_.
34
35 .. note:: The branch to be pushed on ceph-ci can be any branch. The branch does
36 not have to be a PR branch.
37
38 .. note:: If you intend to push master or any other standard branch, check
39 `Shaman`_ beforehand since it might already have completed builds for it.
40
41 .. _the Chacra site: https://shaman.ceph.com/api/search/?status=ready&project=ceph
42
43
44 Triggering Tests
45 ****************
46
47 After you have built Ceph binaries for your branch, you can run tests using
48 teuthology. This procedure explains how to run tests using teuthology.
49
50 #. Log in to the teuthology machine:
51
52 .. prompt:: bash $
53
54 ssh <username>@teuthology.front.sepia.ceph.com
55
56 This requires Sepia lab access. To request access to the Sepia lab, see:
57 https://ceph.github.io/sepia/adding_users/
58
59 #. Run the ``teuthology-suite`` command:
60
61 .. prompt:: bash $
62
63 teuthology-suite -v \
64 -m smithi \
65 -c wip-devname-feature-x \
66 -s fs \
67 -p 110 \
68 --filter "cephfs-shell" \
69 -e foo@gmail.com \
70
71 The options in the above command are defined here:
72
73 ============= =========================================================
74 Option Meaning
75 ============= =========================================================
76 -v verbose
77 -m machine name
78 -c the name of the branch that was pushed on ceph-ci
79 -s test-suite name
80 -p the higher the number, the lower the priority of
81 the job
82 --filter filter tests in a given suite. The argument
83 passed to this filter specifies which test you
84 want to run
85 -e <email> When tests finish or time out, send an email to the
86 specified address. Can also be specified in
87 ~/.teuthology.yaml as 'results_email'
88 ============= =========================================================
89
90 .. note:: The priority number present in the command above is a placeholder.
91 Do not use it in your own tests. See `Testing Priority`_ for information
92 about recommended values.
93
94 .. note:: Do not issue a command without a priority number. The default
95 value is 1000, a value so large that your job is unlikely ever to run.
96
97 Run ``teuthology-suite --help`` to read descriptions of these and other
98 available options.
99
100 #. Wait for the tests to run. ``teuthology-suite`` prints a link to
101 `Pulpito`_ where the test results can be viewed.
102
103
104
105 Other frequently used/useful options are ``-d`` (or ``--distro``),
106 ``--distroversion``, ``--filter-out``, ``--timeout``, ``flavor``, ``-rerun``,
107 ``-l`` (for limiting number of jobs) , ``-N`` (for how many times the job will
108 run), and ``--subset`` (used to reduce the number of tests that are triggered). Run
109 ``teuthology-suite --help`` to read descriptions of these and other options.
110
111 .. _teuthology_testing_qa_changes:
112
113 Testing QA changes (without re-building binaries)
114 *************************************************
115
116 If you are making changes only in the ``qa/`` directory, you do not have to
117 rebuild the binaries before you re-run tests. If you make changes only in
118 ``qa/``, you can use the binaries built for the ceph-ci branch to re-run tests.
119 You just have to make sure to tell the ``teuthology-suite`` command to use a
120 separate branch for running the tests.
121
122 If you made changes only in ``qa/``
123 (https://github.com/ceph/ceph/tree/master/qa), you do not need to rebuild the
124 binaries. You can use existing binaries that are built periodically for master and other stable branches and run your test changes against them.
125 Your branch with the qa changes can be tested by passing two extra arguments to the ``teuthology-suite`` command: (1) ``--suite-repo``, specifying your ceph repo, and (2) ``--suite-branch``, specifying your branch name.
126
127 For example, if you want to make changes in ``qa/`` after testing ``branch-x``
128 (for which the ceph-ci branch is ``wip-username-branch-x``), run the following
129 command
130
131 .. prompt:: bash $
132
133 teuthology-suite -v \
134 -m smithi \
135 -c wip-username-branch-x \
136 -s fs \
137 -p 50 \
138 --filter cephfs-shell
139
140 Then make modifications locally, update the PR branch, and trigger tests from
141 your PR branch as follows:
142
143 .. prompt:: bash $
144
145 teuthology-suite -v \
146 -m smithi \
147 -c wip-username-branch-x \
148 -s fs -p 50 \
149 --filter cephfs-shell \
150 --suite-repo https://github.com/$username/ceph \
151 --suite-branch branch-x
152
153 You can verify that the tests were run using this branch by looking at the
154 values for the keys ``suite_branch``, ``suite_repo`` and ``suite_sha1`` in the
155 job config printed at the beginning of the teuthology job.
156
157 .. note:: If you are making changes that are not in the ``qa/`` directory,
158 you must follow the standard process of triggering builds, waiting
159 for the builds to finish, then triggering tests and waiting for
160 the test results.
161
162 About Suites and Filters
163 ************************
164
165 See `Suites Inventory`_ for a list of available suites of integration tests.
166 Each directory under ``qa/suites`` in the Ceph repository is an integration
167 test suite, and arguments appropriate to follow ``-s`` can be found there.
168
169 Keywords for filtering tests can be found in
170 ``qa/suites/<suite-name>/<subsuite-name>/tasks`` and can be used as arguments
171 for ``--filter``. Each YAML file in that directory can trigger tests; using the
172 name of the file without its filename extension as an argument to the
173 ``--filter`` triggers those tests.
174
175 For example, in the command above in the :ref:`Testing QA Changes
176 <teuthology_testing_qa_changes>` section, ``cephfs-shell`` is specified.
177 This works because there is a file named ``cephfs-shell.yaml`` in
178 ``qa/suites/fs/basic_functional/tasks/``.
179
180 If the filename doesn't suggest what kind of tests it triggers, search the
181 contents of the file for the ``modules`` attribute. For ``cephfs-shell.yaml``
182 the ``modules`` attribute is ``tasks.cephfs.test_cephfs_shell``. This means
183 that it triggers all tests in ``qa/tasks/cephfs/test_cephfs_shell.py``.
184
185 Viewing Test Results
186 ---------------------
187
188 Pulpito Dashboard
189 *****************
190
191 After the teuthology job is scheduled, the status and results of the test run
192 can be checked at https://pulpito.ceph.com/.
193
194 Teuthology Archives
195 *******************
196
197 After the tests have finished running, the log for the job can be obtained by
198 clicking on the job ID at the Pulpito page associated with your tests. It's
199 more convenient to download the log and then view it rather than viewing it in
200 an internet browser since these logs can easily be up to 1 GB in size. It is
201 easier to ssh into the teuthology machine (``teuthology.front.sepia.ceph.com``)
202 and access the following path::
203
204 /ceph/teuthology-archive/<test-id>/<job-id>/teuthology.log
205
206 For example: for the above test ID, the path is::
207
208 /ceph/teuthology-archive/teuthology-2019-12-10_05:00:03-smoke-master-testing-basic-smithi/4588482/teuthology.log
209
210 This method can be used to view the log more quickly than would be possible through a browser.
211
212 .. note:: To access archives more conveniently, ``/a/`` has been symbolically
213 linked to ``/ceph/teuthology-archive/``. For instance, to access the previous
214 example, we can use something like::
215
216 /a/teuthology-2019-12-10_05:00:03-smoke-master-testing-basic-smithi/4588482/teuthology.log
217
218 Killing Tests
219 -------------
220 ``teuthology-kill`` can be used to kill jobs that have been running
221 unexpectedly for several hours, or when developers want to terminate tests
222 before they complete.
223
224 Here is the command that terminates jobs:
225
226 .. prompt:: bash $
227
228 teuthology-kill -r teuthology-2019-12-10_05:00:03-smoke-master-testing-basic-smithi
229
230 Let's call the argument passed to ``-r`` as test ID. It can be found
231 easily in the link to the Pulpito page for the tests you triggered. For
232 example, for the above test ID, the link is - http://pulpito.front.sepia.ceph.com/teuthology-2019-12-10_05:00:03-smoke-master-testing-basic-smithi/
233
234 Re-running Tests
235 ----------------
236
237 The ``teuthology-suite`` command has a ``-r`` (or ``--rerun``) option, which
238 allows you to re-run tests. This is handy when your tests have failed or end
239 up dead. The ``--rerun`` option takes the name of a teuthology run as an
240 argument. Option ``-R`` (or ``--rerun-statuses``) can be passed along with
241 ``-r`` to choose which kind of tests should be picked from the run. For
242 example, you can re-run only those tests from previous run which had ended up
243 as dead. Following is a practical example:
244
245 .. prompt:: bash $
246
247 teuthology-suite -v \
248 -m smithi \
249 -c wip-rishabh-fs-test_cephfs_shell-fix \
250 -p 50 \
251 --r teuthology-2019-12-10_05:00:03-smoke-master-testing-basic-smithi \
252 -R fail,dead,queued \
253 -e $CEPH_QA_MAIL
254
255 Following's the definition of new options introduced in this section:
256
257 ======================= ===============================================
258 Option Meaning
259 ======================= ===============================================
260 -r, --rerun Attempt to reschedule a run, selecting only
261 those jobs whose status are mentioned by
262 --rerun-status.
263 -R, --rerun-statuses A comma-separated list of statuses to be used
264 with --rerun. Supported statuses: 'dead',
265 'fail', 'pass', 'queued', 'running' and
266 'waiting'. Default value: 'fail,dead'
267 ======================= ===============================================
268
269 Naming the ceph-ci branch
270 -------------------------
271 Prepend your branch with your name before you push it to ceph-ci. For example,
272 a branch named ``feature-x`` should be named ``wip-$yourname-feature-x``, where
273 ``$yourname`` is replaced with your name. Identifying your branch with your
274 name makes your branch easily findable on Shaman and Pulpito.
275
276 If you are using one of the stable branches (`quincy`, `pacific`, etc.), include
277 the name of that stable branch in your ceph-ci branch name.
278 For example, the ``feature-x`` PR branch should be named
279 ``wip-feature-x-nautilus``. *This is not just a convention. This ensures that your branch is built in the correct environment.*
280
281 Delete the branch from ceph-ci when you no longer need it. If you are
282 logged in to GitHub, all your branches on ceph-ci can be found here:
283 https://github.com/ceph/ceph-ci/branches.
284
285 .. _ceph-ci: https://github.com/ceph/ceph-ci
286 .. _Chacra: https://github.com/ceph/chacra/blob/master/README.rst
287 .. _Pulpito: http://pulpito.front.sepia.ceph.com/
288 .. _Running Your First Test: ../../running-tests-locally/#running-your-first-test
289 .. _Shaman: https://shaman.ceph.com/builds/ceph/
290 .. _Suites Inventory: ../tests-integration-testing-teuthology-intro/#suites-inventory
291 .. _Testing Priority: ../tests-integration-testing-teuthology-intro/#testing-priority
292 .. _Triggering Tests: ../tests-integration-testing-teuthology-workflow/#triggering-tests
293 .. _tests-sentry-developers-guide: ../tests-sentry-developers-guide/