You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

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:

Test-Parameters: ostcount=2 clients=1 ostsizegb=2 mdssizegb=2 envdefinitions=SLOW=yes \
testlist=replay-dual,replay-single,replay-dual,replay-single,replay-single,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.

Permissible Test-Parameters:

Name

Description

Valid Values

fortestonly

Commit is not indended for landing

 

ostcount

Number of OSTs to test against

1..10

clientprofile

Cobbler profile to use for clients

test

serverprofile

Cobbler profile to use for servers

test

clientdistro

Distribution to use for clients

el5, el6, sl11, ub10

serverdistro

Distribution to use for servers

el5, el6, sl11

clientarch

Architecture to use for clients

i686, x86_64, ppc

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 buildno to fetch for the clients under test

Any valid build no for clientjob

serverjob

Jenkins 'job' to fetch from for the servers under test

Any valid jenkins job

serverbuildno

Jenkins buildno to fetch for the servers under test

Any valid build for serverjob

nettype

Network type to use

tcp, o2ib

clientcount

Number of clients to use

2-4

no_virtualization

Set True if testing must not be virtualized

true

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

filesystemtype

File system to use for OST and MDS

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)
because autotest is create a config file based on the environment it builds and if you
ask for something at odds with autotests expectations you will see failure not success.
In this case for example you should use the filesystemtype described on this page.
Autotest will then create the appropriate environment variables, the same is true for
other things like ost numbers, ost size etc etc. Only use the envdefinitions variable
when a direct variable is not present

AA=BB,CC=DD etc.

testgroup

Test group to test with

review, regression, quick, full

testlist

Comma separated list of test names to run in place of a standard test group

sanity,conf_sanity,mmp etc

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=ppc serverarch=x86_64 \
                 ostcount=10 nettype=tcp tests=conf-sanity,replay-single
Test-Parameters: clientdistro=sl11 serverdistro=rh6 clientarch=ppc \
                 nettype=o2ib tests=conf-sanity,replay-single

Signed-off-by: Random J Developer <random@developer.example.org>
Change-Id: Ica9ed1612eab0c4673dee088f8b441d806c64932
  • No labels