There may be times that you wish to influence the building and testing carried out on your change. You might for example be fixing an issue that affects a particular distribution or combination of distributions, for this reason you can change the tests carried out by indicating in the commit message the changes you require.
To do this place the following comments with space-separated name value pairs in your commit message:
Test-Parameters: n=v x=y
To cater for multiple requirements we allow for lists of requirements, with each entry being a separate test:
Test-Parameters: x=y c=e Test-Parameters: e=z r=e
Long lists can be catered for by escaping the carriage return:
Test-Parameters: ostcount=2 clients=1 ostsizegb=2 mdssizegb=2 envdefinitions=SLOW=yes \ testlist=sanity,liblustre
Multiple tests are separated by a comma, and can be specified multiple times. This is useful if a patch is fixing a problem that is only hit intermittently by a test script, and multiple tests need to be run in order to gain more confidence that the problem is actually fixed. For example, if replay-dual was failing 1/3 of test runs, it would be useful to run it at least twice the average number of times needed to hit a failure to have some reasonable expectation that the bug is fixed. With just a single test run, there would be a 66% chance a single test would pass even if the bug was not fixed, but only about a 9% chance (2/36 = 64/729) that 6 separate tests would pass. If the number of tests needed is more than about 5-6, then multiple Test-Parameters: lines may be used, so that the tests are run in separate sessions (usually in parallel) rather than in series.
Test-Parameters: ostcount=2 clients=1 ostsizegb=2 mdssizegb=2 envdefinitions=SLOW=yes \
testlist=replay-dual,replay-dual,replay-dual,replay-dual,replay-dual,replay-dual
fortestonly
Test-Parameters: supplied with a normal commit are in addition to the normal tests that would be run against a patch. This allows a patch with specific or unusual testing requirements to ensure that sufficient additional testing is run to gain confidence in the change being made. For patches that are of an experimental nature (i.e. developer is not sure of functionality, or only wants a limited set of tests to be run), it is also possible to submit a patch with the fortestonly parameter.
The fortestonly parameter marks that the patch is not intended for landing. Supplied Test-Parameters override the default tests that will be run, so it is possible to run only a subset of tests, possibly multiple times each. Patches marked with fortestonly will not receive the Verified label from Maloo and cannot be landed without being resubmitted, or editing the commit comment in Gerrit to remove the fortestonly label and allowing the tests to complete (which will preserve any reviews that the patch has received).
Permissible Test-Parameters: options
Name | Description | Valid Values |
|---|---|---|
fortestonly | Patch will be built by Jenkins. A single review test session will be run by default, unless another specific test list is specified using the |
|
| forbuildonly | Patch will be built by Jenkins, but no testing will be done. The Verified flag will not be set by Maloo for landing. | |
| trivial | Patch only contains whitespace, comment or man page updates and requires minimal testing. Currently, only review-ldiskfs is run for trivial patches (see Autotest Plan for full details). | |
clientcount | Number of clients to use | 2-4 |
mdscount | Number of MDSs to test against | 1-4 |
mdtcount | Number of MDTs to test against | 1-4 |
osscount | Number of OSTs to test against | 1-4 |
ostcount | Number of OSTs per OSS to test against | 1-4 |
clientprofile | Cobbler profile to use for clients | test |
serverprofile | Cobbler profile to use for servers | test |
clientdistro | Distribution to use for clients | el6, el7, sles11, sles11sp2 |
serverdistro (A bug exists today which means you need to specify mdsdistro & ossdistro not serverdistro) | Distribution to use for servers | el6, el7, sles11, sles11sp2 |
clientarch | Architecture to use for clients | i686, x86_64, ppc64 |
serverarch serverdistro (A bug exists today which means you need to specify mdsarch & ossarch not serverarch) | Architecture to use for servers | i686, x86_64 |
clientjob | Jenkins 'job' to fetch from for the clients under test | Any valid Jenkins job |
clientbuildno | Jenkins build number to fetch for the clients under test | Any valid Jenkins buildno for clientjob |
serverjob serverdistro (A bug exists today which means you need to specify mdsjob & ossjob not serverjob) | Jenkins 'job' to fetch from for the servers under test | Any valid jenkins job |
serverbuildno | Jenkins build number to fetch for the servers under test | Any valid build for serverjob |
nettypes | Network types to use as a comma separated array | tcp, o2ib |
ostsizegb | Size of OSTs in GB. Note this is a max size and will be limited by the disk available | >0 |
mdssizegb | Size of MDS in GB. Note this is a max size and will be limited by the disk available | >0 |
mdsfilesystemtype | File system to use for MDSs | zfs, ldiskfs |
mdtfilesystemtype | File system to use for MDTs | zfs, ldiskfs |
ostfilesystemtype | File system to use for OSTs | zfs, ldiskfs |
clientibstack | IB stack to use on the client. | inkernel, ofa |
serveribstack | IB stack to use on the server. | inkernel, ofa |
envdefinitions | Comma separated environment definitions passed to the environment. Be very careful setting environment variables directly (for example OSTFSTYPE=zfs) | AA=BB,CC=DD etc. |
testgroup | Test group to test with | review, regression, full, review-ldiskfs, review-dne-part-1, review-dne-part2, review-zfs-part1, review-zfs-part-2, etc. |
testlist | Comma separated list of test names to run in place of a standard test group | sanity, conf-sanity, mmp, replay-single, replay-dual, lnet-selftest, etc. |
| alwaysuploadlogs | By default autotest will upload logs on passing tests. This will force it do upload logs. This option is no longer necessary. | |
| failover | Setup cluster in failover configuration | |
| iscsi | Use iSCSI for failover testing | 0, 1 |
You do not need to specify all the values only those values important for your requirements, the test system will use your request to alter a regular test. Also to ensure that you all reviews are fully tested to a known standard. The test system will run a regular, unmodified test set as well as the special request.
Here is an example:
LU-1234 recovery: handle swabbing during recover
Handle byte swabbing of requests properly during recovery. There were
problems with the handling of replayed creates that sent the requests
with client-endian order but a little-endian LOV EA.
Test-Parameters: clientdistro=el5 clientarch=ppc64 serverarch=x86_64 \
ostcount=10 nettype=tcp testlist=conf-sanity,replay-single
Test-Parameters: clientdistro=sles11 clientarch=ppc64 serverdistro=el6 \
nettype=o2ib testlist=conf-sanity,replay-single
Signed-off-by: Random J Developer <random@developer.example.org>
Change-Id: Ica9ed1612eab0c4673dee088f8b441d806c64932
Complex Examples
Test a review for failover
Test-Parameters: fortestonly envdefinitions="SLOW=yes" clientcount=4 osscount=2 mdscount=2 austeroptions=-R failover=true iscsi=1 testgroup=failover
Overview
Content Tools