Page History
Table of Contents |
---|
Introduction
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:
Code Block |
---|
Test-Parameters: trivial envdefinitions=ONLY=32 testlist=conf-sanity
|
To cater for multiple requirements we allow for lists of requirements, with each Test-Parameters:
line being a separate test that can be run in parallel with other tests:
Code Block |
---|
Test-Parameters: trivial ostfilesystemtype=ldiskfs testlist=sanity,sanity,sanity,sanity
Test-Parameters: trivial ostfilesystemtype=zfs testlist=sanity,sanity,sanity,sanity
|
Long lists can be catered for by escaping the carriage return:
Code Block |
---|
Test-Parameters: ostcount=2 clients=1 ostsizegb=2 mdssizegb=2 envdefinitions=SLOW=yes \
testlist=sanity,liblustre
|
testlist=
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 without the bug being fixed. If the number of tests needed is more than about 3-4 (depending on how long each test runs), then multiple Test-Parameters:
lines should be used, so that the tests are run in separate sessions (usually in parallel) rather than in series.
Code Block |
---|
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 just to try something), it is also possible to submit a patch with the fortestonly
parameter.
The fortestonly
parameter marks that the patch is not intended for landing. Any testlist=
specified with Test-Parameters:
fortestonly
will replace 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. In order to land such a patch, it should be rebased and submitted without the fortestonly
keyword once the patch is known to be good, or the commit comment in Gerrit should be edited to remove the fortestonly
label which will rebuild and retest the patch and will preserve any reviews that the patch has received).
trivial
The trivial
keyword can be used to reduce the testing time (both wall-clock time as well as total test system hours) for patches that do not affect code functionality, such as changes to whitespace, comments, man pages, and test scripts (in conjunction with the testlist
keyword to ensure the modified test script is run if it isn't already). Patches marked with trivial
in the Test-Parameters:
list will run the review-ldiskfs
test session instead of the regular tests, so it currently runs only sanity
and lnet-selftest
to ensure basic functionality. If changes are only being made to a test script outside of those already run by default, an additional testlist=<test-script(s)>
keyword should be added with a comma-separated list of modified tests to ensure they are run to validate the changes. The trivial
keyword will reduce the test completion time from approximately 10h elapsed and 30h of total test system time to approximately 3h elapsed/system time. This saves test system resources that may be better spent on other patches.
Permissible Test-Parameters:
options
...
Name
...
Description
...
Valid Values
...
testgroup
...
Test group to test with. testgroup can be combined with testlist:
Code Block |
---|
Test-Parameters: testgroup=review-ldiskfs testlist=sanity-selinux |
will run the review-ldiskfs test group and the sanity-selinux test suite
...
review
, regression
, full
, review-ldiskfs
, review-dne-part-1
, review-dne-part-2
, review-zfs-part-1
, review-zfs-part-2
, etc.
...
testlist
...
Comma separated list of test names to run in place of a standard test group. testlist can be combined with testgroup. See testgroup for an example.
...
, sanity
,sanitynconf-sanity
, mmp
, replay-single
, replay-dual
, lnet-selftest
, etc.
...
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 testlist=
parameter. The Verified
flag will not be set by Maloo for landing.
...
...
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
...
mdsprofile
,
ossprofile
...
Cobbler profile to use for servers
...
test
...
clientdistro
...
Distribution to use for clients
...
el6
, el7
, sles11
, sles11sp2
...
mdsdistro
, ossdistro
...
Distribution to use for servers
...
el6
, el7
, sles11
, sles11sp2
...
clientarch
...
Architecture to use for clients
...
i686
, x86_64
, ppc64
...
mdsarch
, ossarch
...
Architecture to use for servers
...
i686
, x86_64
...
clientjob
...
Jenkins 'job' to fetch from for the clients under test
...
Any valid Jenkins job, such as lustre-reviews
, lustre-master
, etc.
...
clientbuildno
...
Jenkins build number to fetch for the clients under test
...
Any valid Jenkins buildno for clientjob
...
mdsjob
, ossjob
...
Jenkins 'job' to fetch from for the servers under test
...
Any valid Jenkins job, such as lustre-reviews
, lustre-master
, etc.
...
serverbuildno
...
Jenkins build number to fetch for the servers under test
...
Any valid Jenkins build number for mdsjob
or ossjob
...
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
...
mdtfilesystemtype
...
File system to use for MDTs and MGS
...
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.
Panel |
---|
Be very careful setting environment variables directly (for example |
...
ONLY=26
,EXCEPT=22
...
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:
Code Block |
---|
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 Parameter sessions 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 just to try something), it is also possible to submit a patch with the fortestonly
parameter.
To run additional sessions for your patch, add 'Test-Parameters: ' with space-separated name value pairs to your commit message.
For example:
Code Block | ||
---|---|---|
| ||
Test-Parameters: env=ONLY=32 testlist=conf-sanity |
This will cause Autotest to run the normal test sessions plus 1 additional session where only conf-sanity test #32 will run. The parameters specified in Test-Parameters
do not affect the existing sessions that are run by default.
Multiple 'Test-Parameters:' lines can be defined, with each Test-Parameters
line triggering a separate test session to run in parallel with the default test sessions:
Code Block | ||
---|---|---|
| ||
Test-Parameters: testgroup=review-ldiskfs clientdistro=sles12sp3 serverdistro=sles12sp3
Test-Parameters: testgroup=review-ldiskfs clientdistro=ubuntu1804 serverdistro=el7 |
Long lists can be catered for by escaping the carriage return:
Code Block | ||
---|---|---|
| ||
Test-Parameters: ostcount=2 clients=1 ostsizegb=2 mdssizegb=2 env=SLOW=yes \
testlist=sanity,liblustre |
Quotations can be used when spaces are necessary in a value:
Code Block | ||
---|---|---|
| ||
Test-Parameters: testlist=sanity env=SANITY_EXCEPT="101g 102i" |
The test parameter sessions can be influenced in many ways, see the General Parameters and Node Parameters sections below for all of the options.
Anchor | ||||
---|---|---|---|---|
|
Build Parameters
Below are build parameters read by Jenkins, and the Lustre Janitor.
Panel | |||||
---|---|---|---|---|---|
| |||||
Signals to all components the patch is intended for Lustre Janitor testing only. Jenkins will not build the patch (the status will be FAILURE) and therefore, Autotest will not test it. Your patch will not receive a +/- 1 from Maloo.
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Signals to all components the patch should be completely ignored. Jenkins will not build the patch (the status will be FAILURE) and it will not be tested by Autotest or the Lustre Janitor. Your patch will not receive a +/- 1 from Maloo.
|
Anchor | ||||
---|---|---|---|---|
|
General Parameters
Below is the list of general test parameters that can be used to run custom test sessions. These parameters differ from the node_parameters in that these do not need to be specified with a node type prefix.
For all of the examples below the 'Test-Parameters:' marker has been omitted to simplify the examples.
Panel | |||||
---|---|---|---|---|---|
| |||||
Pass through options for auster. Valid values: See "Auster usage help" section on the Setting up a Lustre Test Environment wiki.
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
When true, the MGT will share a partition with an MDT. When false, AT will create an additional partition to be used by just the MGT. NOTE: mdtfilesystemtype will override mgtfilesystemtype when combinedmdsmgs is true. If standalonemgs is set to true, this option will be ignored. Valid values: true, false (no value is the same as true)
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Comma separated environment definitions passed to the test environment. For definitions requiring spaces, enclose them in quotations. NOTE: Be very careful setting environment variables directly (for example OSTFSTYPE=zfs) because Autotest creates a config file based on the environment it builds. If you ask for something at odds with Autotest's expectations you will see failure instead of success. In this case, for example, you should use the filesystemtype keyword described on this page. Autotest will then create the appropriate environment variables, the same is true for other things like ostcount instead of OSTCOUNT, ostsizegb instead of OSTSIZE, etc. Only use the env parameter when a direct variable is not listed here.
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Used to specify which node should run the test framework. Default is client1. Valid values: mds1, oss1, client2, etc.
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Setup cluster in failover configuration Valid values: true, false (no value is the same as true)
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Patch will be built by Jenkins but Autotest will not run any testing. Valid values: true, false (no value is the same as true)
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
The Valid values: true, false (no value is the same as true)
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Sets the file system type for all server nodes (MDS, MGS and OSS). NOTE: fstype should not be used in combination with <mdt/mgt/ost>filesystemtype. Valid values: ldiskfs, zfs
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Use iSCSI for failover testing Valid values: 0 (no iSCSI), 1 (iSCSI)
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Set the cluster up to use Kerberos Valid values: true, false (no value is the same as true)
|
Panel | ||
---|---|---|
| ||
For DDN employees only: How to: livedebug |
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
The total number of MDS nodes in the cluster. Valid values: 1 - 8 MDS nodes
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Sets the size of the partitions on the MDS in GB. Valid values: > 0 and must be an integer. When setting this value, take into consideration your mdtcount value and that most test nodes have ~90GB of disk space.
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
The total number of MDTs across all of the MDSs. Valid values: 1 - 4 per MDS
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Configure the file system type to use on the MDTs. NOTE: <mdt/mgt/ost>filesystemtype should not be used in combination with fstype. Valid values: ldiskfs, zfs
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Sets the size of the partition on the MGS in GB. This value is only applicable when the session is using a stand alone MGS. Valid values: > 0 and must be an integer. When setting this value, take into consideration that most test nodes have ~90GB of disk space.
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Configure the file system type to use on the MGTs. NOTE: The default value for combinedmdsmgs is true, therefore it must be set to false in order to configure a different file system type for the MGT. Also, <mdt/mgt/ost>filesystemtype should not be used in combination with fstype. Valid values: ldiskfs, zfs
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Marks the test session as optional: does not impact the verified value from Maloo and is only run if resources are immediately available. Valid values: true, false (no value is the same as true)
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
The number of OSTs per OSS. Valid values: 1 - 8
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Configure the file system type to use on the OSTs. NOTE: <mdt/mgt/ost>filesystemtype should not be used in combination with fstype. Valid values: ldiskfs, zfs
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Sets the size of the partitions on the OSS in GB. Valid values: > 0 and must be an integer. When setting this value, take into consideration your ostcount value and that most test nodes have ~90GB of disk space.
|
Panel | |||||
---|---|---|---|---|---|
| |||||
When true, Autotest will continue the session after a suite crashes. The session will continue with the suite following the one that crashed. When false, Autotest will stop the session and upload the results to Maloo immediately. Valid values: true, false (no value is the same as true)
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Marks the session as enforcing: is used to determine the verified value from Maloo. Valid values: true, false (no value is the same as true)
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Provisions a separate test node as the MGS. The MGS will be setup with the same parameters as the MDS unless they're overwritten. Valid values: true, false (no value is the same as true)
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Specifies the subproject of the patch. Subprojects must be added by Autotest Admin, currently the only configured subproject is lnet. Valid values: lnet
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Configure the test session to run a specific test group. Specifying a test group makes it easy to run a typical test grouping with small modifications since the session will inherit all of the values from the base test with any overrides applied (see the code block below for examples). NOTE: testgroup can be combined with testlist to run a test group plus additional suites Valid values: See the Test Groups section for a complete list
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Configure the test session to run a specific list of suites. testlist can be combined with testgroup to run a test group plus additional suites. Valid values: sanity, sanityn, conf-sanity, mmp, replay-single, replay-dual, lnet-selftest, etc.
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Configures the session to re-provision all of the nodes instead of simply reboot them. Valid values: true, false (no value is the same as true)
|
Panel | |||||
---|---|---|---|---|---|
| |||||
The Valid values: true, false (no value is the same as true)
|
Anchor | ||||
---|---|---|---|---|
|
Node Parameters
Node parameters are used to change how specific node types are configured. They must be prefixed with the node type being changed. Valid node types are client, mds, mgs, oss and server. Server is an alias that allows users to modify a value for all server node types (mds, mgs and oss). For example instead of writing
Code Block | ||
---|---|---|
| ||
mdsdistro=el7 mgsdistro=el7 ossdistro=el7 |
Users can simply write
Code Block | ||
---|---|---|
| ||
serverdistro=el7 |
Panel | |||||
---|---|---|---|---|---|
| |||||
Sets the architecture for the specified node type Valid values: x86_64, ppc64, aarch64 (architecture must have been built for patch)
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Used in conjunction with job to install a specific build on the specified node. job must be specified with buildno and version cannot be specified with buildno. Valid values: Any valid Jenkins build number for the specified job
|
Panel | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
The number of nodes to use for the specified node type. NOTE: For MDS and OSS nodes, it's best to also set mdtcount / ostcount to ensure you have the expected number of targets. Valid values:
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Distribution to use for the specified node type. Valid values: el7, el7.5, el7.6, ubuntu1604, ubuntu1804, sles12sp3, etc. (The distribution specified must have been built for the patch being tested. The distros built can be seen on the patch's build page in Jenkins.)
|
Panel | |||||
---|---|---|---|---|---|
| |||||
The IB stack to use for the specified node type. Valid values: inkernel, ofa (The IB stack type must have been built for the build being tested. The stack types can be seen on the patch's build page in Jenkins.)
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Used with buildno to install a specific build on the specified node. buildno must be specified with job. version cannot be specified with job. Valid values: Any valid Jenkins job, such as lustre-reviews, lustre-master, etc.
|
Panel | |||||
---|---|---|---|---|---|
| |||||
Enables selinux on the specified node type. Valid values: true, false (no value is the same as true)
|
Anchor | ||||
---|---|---|---|---|
|
Panel | |||||
---|---|---|---|---|---|
| |||||
The version of Lustre to use for the specified node type. Version cannot be specified with job and build. If a distro is not specified in the test parameters, Autotest will use the highest el version available for the specified version. Valid values: For a list of valid versions see the Versions section.
Note that in addition to the more commonly used |
Anchor | ||||
---|---|---|---|---|
|
Versions
Versions are pointers to job/build combinations and simplify using a specific Lustre version on a test node. Versions can be specified in the test parameters using the version node parameter.
The versions in parenthesis auto-update as new versions are added. For example 1.9 will always point to the highest 1.9.x version. EXA1 will always point to the highest EXA1.x.x version.
If there is a version missing, send an email to charlie@whamcloud.com
Version | Build |
---|---|
2.7.0 (2.7) | |
2.8.0 (2.8) | |
2.9.0 (2.9) | |
2.10.0 | |
2.10.1 | |
2.10.2 | |
2.10.3 | |
2.10.4 | |
2.10.5 | |
2.10.6 | |
2.10.7 | |
2.10.8 (2.10) | |
2.11.0 (2.11) | |
2.12.0 | |
2.12.1 | |
2.12.2 | |
2.12.3 | |
2.12.4 | |
2.12.5 | |
2.12.6 | |
2.12.7 | |
2.12.8 | |
2.12.9 (2.12) | |
2.13.0 (2.13) | |
2.14.0 (2.14) | |
2.15.0 | |
2.15.1 | https://build.whamcloud.com/job/lustre-b2_15/28/ |
2.15.2 | https://build.whamcloud.com/job/lustre-b2_15/48/ |
2.15.3 | https://build.whamcloud.com/job/lustre-b2_15/65/ |
2.15.4 (2.15) | https://build.whamcloud.com/job/lustre-b2_15/81 |
EXAScaler Versions |
Anchor | ||||
---|---|---|---|---|
|
Test Groups
Test groups are set lists of Lustre test suites managed by Autotest.
Name | Suites |
---|---|
basic | conf-sanity |
failover-part-1 | replay-vbr, replay-dual, replay-single, mmp, replay-ost-single, recovery-small, recovery-double-scale |
failover-part-2 | recovery-random-scale |
failover-part-3 | recovery-mds-scale |
failover-zfs-part-1 | replay-vbr, replay-dual, replay-single, mmp, replay-ost-single, recovery-small, recovery-double-scale |
failover-zfs-part-2 | recovery-random-scale |
failover-zfs-part-3 | recovery-mds-scale |
full-dne-part-1 | sanity-scrub, replay-single, obdfilter-survey, replay-ost-single, large-scale, insanity, parallel-scale, runtests, replay-dual, sanity-flr, sanity-lsnapshot, mmp, sanity-dom, mds-survey, sanity-lfsck, sanity-lnet, pjdfstest, ost-pools, recovery-small |
full-dne-part-2 | lnet-selftest, sanity, sanity-hsm, lustre-rsync-test, sanity-sec, replay-vbr, parallel-scale-nfsv3, sanity-quota, sanity-pcc, sanity-lipe-find3, racer |
full-dne-part-3 | sanity-pfl, performance-sanity, sanity-benchmark, conf-sanity, sanityn, parallel-scale-nfsv4, hot-pools, sanity-lipe, sanity-lipe-scan3 |
full-dne-zfs-part-1 | sanity-scrub, replay-single, obdfilter-survey, replay-ost-single, large-scale, insanity, parallel-scale, runtests, replay-dual, sanity-flr, sanity-lsnapshot, mmp, sanity-dom, mds-survey, sanity-lfsck, sanity-lnet, pjdfstest, ost-pools, recovery-small |
full-dne-zfs-part-2 | lnet-selftest, sanity, sanity-hsm, lustre-rsync-test, sanity-sec, replay-vbr, parallel-scale-nfsv3, sanity-quota, sanity-pcc, sanity-lipe-find3, racer |
full-dne-zfs-part-3 | sanity-pfl, performance-sanity, sanity-benchmark, conf-sanity, sanityn, parallel-scale-nfsv4, hot-pools, sanity-lipe, sanity-lipe-scan3 |
full-part-1 | sanity-scrub, replay-single, obdfilter-survey, replay-ost-single, large-scale, insanity, parallel-scale, runtests, replay-dual, sanity-flr, sanity-lsnapshot, mmp, sanity-dom, mds-survey, sanity-lfsck, sanity-lnet, pjdfstest, ost-pools, recovery-small |
full-part-2 | lnet-selftest, sanity, sanity-hsm, lustre-rsync-test, sanity-sec, replay-vbr, parallel-scale-nfsv3, sanity-quota, sanity-pcc, sanity-lipe-find3, racer |
full-part-3 | sanity-pfl, performance-sanity, sanity-benchmark, conf-sanity, sanityn, parallel-scale-nfsv4, hot-pools, sanity-lipe, sanity-lipe-scan3 |
full-patchless | lnet-selftest, runtests, sanity, sanity-scrub, sanity-benchmark, sanity-lfsck, sanityn, sanity-hsm, sanity-flr, sanity-dom, sanity-lsnapshot, insanity, sanity-quota, sanity-sec, sanity-pfl, lustre-rsync-test, ost-pools, mds-survey, mmp, performance-sanity, parallel-scale, large-scale, obdfilter-survey, parallel-scale-nfsv3, parallel-scale-nfsv4, pjdfstest, sanity-lnet, racer |
full-zfs-dkms | sanity-scrub, replay-single, obdfilter-survey, replay-ost-single, large-scale, insanity, parallel-scale, runtests, replay-dual, sanity-flr, sanity-lsnapshot, mmp, sanity-dom, mds-survey, sanity-lfsck, sanity-lnet, pjdfstest, ost-pools, recovery-small |
full-zfs-part-1 | sanity-scrub, replay-single, obdfilter-survey, replay-ost-single, large-scale, insanity, parallel-scale, runtests, replay-dual, sanity-flr, sanity-lsnapshot, mmp, sanity-dom, mds-survey, sanity-lfsck, sanity-lnet, pjdfstest, ost-pools, recovery-small |
full-zfs-part-2 | lnet-selftest, sanity, sanity-hsm, lustre-rsync-test, sanity-sec, replay-vbr, parallel-scale-nfsv3, sanity-quota, sanity-pcc, sanity-lipe-find3, racer |
full-zfs-part-3 | sanity-pfl, performance-sanity, sanity-benchmark, conf-sanity, sanityn, parallel-scale-nfsv4, hot-pools, sanity-lipe, sanity-lipe-scan3 |
lnet-review-ldiskfs-dne | lnet-selftest, sanity, sanity-lnet, sanity-sec |
review | lnet-selftest, runtests, sanity, sanityn, replay-single, conf-sanity, recovery-small, replay-ost-single, insanity, sanity-quota, lustre-rsync-test, ost-pools, sanity-lfsck, sanity-hsm, sanity-lnet |
review-dne-part-1 | sanity, sanity-pfl |
review-dne-part-2 | mds-survey, replay-dual, runtests, sanity-lfsck, sanity-sec |
review-dne-part-3 | conf-sanity |
review-dne-part-4 | insanity, mmp, replay-ost-single, sanity-dom, sanity-flr, sanity-hsm, sanity-quota |
review-dne-part-5 | lustre-rsync-test, recovery-small, sanity-scrub, sanityn |
review-dne-part-6 | replay-single, ost-pools |
review-dne-part-7 | large-scale, hot-pools, sanity-pcc, sanity-lipe |
review-dne-part-8 | parallel-scale, replay-vbr, replay-dual, racer |
review-dne-part-9 | obdfilter-survey, performance-sanity, sanity-benchmark, parallel-scale-nfsv4, parallel-scale-nfsv3 |
review-dne-selinux-ssk-part-1 | sanity |
review-dne-selinux-ssk-part-2 | recovery-small, sanity-sec, sanity-selinux |
review-dne-zfs | runtests, sanity, sanityn, replay-single, conf-sanity, recovery-small, replay-ost-single, insanity, sanity-quota, lustre-rsync-test, ost-pools, sanity-lfsck, sanity-hsm |
review-dne-zfs-part-1 | sanity, sanity-pfl |
review-dne-zfs-part-2 | mds-survey, replay-dual, runtests, sanity-lfsck, sanity-sec |
review-dne-zfs-part-3 | conf-sanity |
review-dne-zfs-part-4 | insanity, mmp, replay-ost-single, sanity-dom, sanity-flr, sanity-hsm, sanity-quota |
review-dne-zfs-part-5 | lustre-rsync-test, recovery-small, sanity-scrub, sanityn |
review-dne-zfs-part-6 | replay-single, ost-pools |
review-dne-zfs-part-7 | large-scale, hot-pools, sanity-pcc, sanity-lipe |
review-exa6 | sanity-pcc, sanity-sec |
review-ldiskfs | lnet-selftest, sanity, sanity-lnet |
review-ldiskfs-arm | lnet-selftest, sanity, sanity-lnet |
review-ldiskfs-dne | lnet-selftest, sanity, sanity-lnet |
review-ldiskfs-dne-arm | lnet-selftest, sanity, sanity-lnet |
review-ldiskfs-ubuntu | lnet-selftest, sanity, sanity-lnet |
review-zfs | sanity-quota, sanity-flr, replay-single, replay-ost-single, insanity |
review-zfs-part-1 | runtests, sanity, sanityn, sanity-quota, ost-pools, sanity-lfsck, sanity-hsm, sanity-flr |
review-zfs-part-2 | replay-single, conf-sanity, recovery-small, replay-ost-single, insanity, lustre-rsync-test, large-scale, mds-survey |
tiny | sanity, mmp |