iyermanoj | 5e1abfd | 2002-04-04 20:22:01 +0000 | [diff] [blame] | 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 |
Chris Dearman | 37550cf | 2012-10-17 19:54:01 -0700 | [diff] [blame] | 20 | if there are failures the output from each testcase. |
iyermanoj | 5e1abfd | 2002-04-04 20:22:01 +0000 | [diff] [blame] | 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 | |
Chris Dearman | 37550cf | 2012-10-17 19:54:01 -0700 | [diff] [blame] | 45 | #2 ltp_master system.name.dom.com |
iyermanoj | 5e1abfd | 2002-04-04 20:22:01 +0000 | [diff] [blame] | 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 |
Chris Dearman | 37550cf | 2012-10-17 19:54:01 -0700 | [diff] [blame] | 52 | distros, platforms etc, for example, We might say have a file with RedHat |
iyermanoj | 5e1abfd | 2002-04-04 20:22:01 +0000 | [diff] [blame] | 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 | ~~~~~~~~~~~~~ |
Chris Dearman | 37550cf | 2012-10-17 19:54:01 -0700 | [diff] [blame] | 63 | ltprun is where bulk of the automation of ltp is done. |
iyermanoj | 5e1abfd | 2002-04-04 20:22:01 +0000 | [diff] [blame] | 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 |
Chris Dearman | 37550cf | 2012-10-17 19:54:01 -0700 | [diff] [blame] | 85 | - parses results gathered, saves it as results.out file in the same |
iyermanoj | 5e1abfd | 2002-04-04 20:22:01 +0000 | [diff] [blame] | 86 | directory. The results are sorted by system name and then run time. |
| 87 | |
Chris Dearman | 37550cf | 2012-10-17 19:54:01 -0700 | [diff] [blame] | 88 | Note: |
iyermanoj | 5e1abfd | 2002-04-04 20:22:01 +0000 | [diff] [blame] | 89 | - Check through the scripts for appropriate variables that you may need to |
Chris Dearman | 37550cf | 2012-10-17 19:54:01 -0700 | [diff] [blame] | 90 | change in order to customize further, they should be at the beginning of the |
iyermanoj | 5e1abfd | 2002-04-04 20:22:01 +0000 | [diff] [blame] | 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 |