tools/README

   1 LTP Automation
   2 ~~~~~~~~~~~~~~~
   3
   4 The LTP automation scripts are intended to completely automate the
   5 updating, running, and reporting of an LTP test run. The ltpupdate script
   6 simply produces a copy of the latest CVS code and packages it up as a tgz
   7 file and uploads it to the designated LTP host machine. The ltp_master
   8 script first kicks off the test (this could possibly be controlled by another
   9 script say after a new release for example). This script uploads the
  10 ltprun script (which does the actual test run) to each machine specified.
  11 Currently I use this mostly as a single shot run. I envision a time to come
  12 when I have enough machines to run a copy of LTP against a test farm of say
  13 the same distro on different machine configurations, or on every machine I
  14 have control over for example. The ltprun scripts does what one would
  15 usually do on a system to be tested, download the code, compile, execute,
  16 but it also handles the reporting process as well. It will upload the data
  17 to the LTP host to be collected later. The ltp_check script does the brunt
  18 of the results processing. It produces a results.out file which has a
  19 summary of the system under test, the success (or failure) of the test and
  20 if there are failures the output from each testcase.
  21
  22 Here's the scenario (pardon the ASCII art);
  23
  24 ----------  ------            -----------
  25 |master|    |test|            |ltp_host|
  26 ----------  ------            -----------
  27   |             |                     |
  28   +-------------+---------------------+
  29
  30
  31 I've divided it up into 3 machine types viz, "master", "test" and
  32 "ltp_host". For purposes of this documents lts consider we have one test
  33 machine.
  34
  35 ltp_master script
  36 ~~~~~~~~~~~~~~~~~
  37 The ltp_master script is the driver that runs LTP testsuite on a machine
  38 of choice, it takes a single argument ie the name of the victim machine
  39
  40 ltp_master can be invoked in the following 3 ways:
  41
  42 #1 ltp_master -f system_file
  43  - system_file is an ASCII file containing the list of victim machines.
  44
  45 #2 ltp_master system.name.dom.com
  46  - space separated names of victim machines.
  47
  48 #3 ltp_master
  49  - will prompt user for the names of the victim machines.
  50
  51 I reccomend using scheme #2, this will help seperate different
  52 distros, platforms etc, for example, We might say have a file with RedHat
  53 machines, or all SuSE, or all machines of a certain platform (say zSeries).
  54
  55 Regardless of how it's invoked ltp_master does the following on each
  56 victim machine.
  57
  58   -  FTP connect to the test system and uploads ltprun
  59   -  Telnet to each system and kick off ltprun ( runs under nohup )
  60
  61 ltprun script
  62 ~~~~~~~~~~~~~
  63 ltprun is where bulk of the automation of ltp is done.
  64 It does the following.
  65   - downloads the ltp test suite tarfile (ltp.tgz) from ltp_host.
  66   - uncompress the test suite and compile it.
  67   - runs the test suite.
  68   - tars up the results.
  69   - uploads results back to ltp_host.
  70
  71 In case any of the get, build, run fails, the script will still upload
  72 the results back to the ltp_host machine, so you don't have to try to remember
  73 which runs were kicked off and correlate that with which runs were reported.
  74
  75 ltp_check
  76 ~~~~~~~~~
  77 ltp_check lives on the master machine, this script has to be run as root
  78 user and it saves the ltp test results in /root/ltp_results.
  79
  80 ltp_check does the following;
  81   - FTPs to ltp_host and downloads all of the *-ltpoutput.tgz files
  82   - Creates a results directory for each machine (using the short
  83     hostname) and for each run (based on timestamping)
  84   - Uncompresses the gathered result files into the new directory
  85   - parses results gathered,  saves it as results.out file in the same
  86     directory. The results are sorted by system name and then run time.
  87
  88 Note:
  89   - Check through the scripts for appropriate variables that you may need to
  90 change in order to customize further, they should be at the beginning of the
  91 file.
  92
  93   - This "fire and forget" might not work 100%. But if you find a test
  94 (like pth_str02) that hangs you can log in as root and do something like;
  95 killall pth_str02 a few times and the test should pick up where it left
  96 off.
  97
  98 Please send comments or suggestions to:
  99
 100 Jay Huie
 101 wjhuie@us.ibm.com
 102 Linux System Test
 103 Phone: 845-435-8164