Home | History | Annotate | Download | only in tools 
      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 (a] us.ibm.com
    102 Linux System Test
    103 Phone: 845-435-8164
    104