| LTP Automation |
| ~~~~~~~~~~~~~~~ |
| |
| The LTP automation scripts are intended to completely automate the |
| updating, running, and reporting of an LTP test run. The ltpupdate script |
| simply produces a copy of the latest CVS code and packages it up as a tgz |
| file and uploads it to the designated LTP host machine. The ltp_master |
| script first kicks off the test (this could possibly be controlled by another |
| script say after a new release for example). This script uploads the |
| ltprun script (which does the actual test run) to each machine specified. |
| Currently I use this mostly as a single shot run. I envision a time to come |
| when I have enough machines to run a copy of LTP against a test farm of say |
| the same distro on different machine configurations, or on every machine I |
| have control over for example. The ltprun scripts does what one would |
| usually do on a system to be tested, download the code, compile, execute, |
| but it also handles the reporting process as well. It will upload the data |
| to the LTP host to be collected later. The ltp_check script does the brunt |
| of the results processing. It produces a results.out file which has a |
| summary of the system under test, the success (or failure) of the test and |
| if there are failures the output from each testcase. |
| |
| Here's the scenario (pardon the ASCII art); |
| |
| ---------- ------ ----------- |
| |master| |test| |ltp_host| |
| ---------- ------ ----------- |
| | | | |
| +-------------+---------------------+ |
| |
| |
| I've divided it up into 3 machine types viz, "master", "test" and |
| "ltp_host". For purposes of this documents lts consider we have one test |
| machine. |
| |
| ltp_master script |
| ~~~~~~~~~~~~~~~~~ |
| The ltp_master script is the driver that runs LTP testsuite on a machine |
| of choice, it takes a single argument ie the name of the victim machine |
| |
| ltp_master can be invoked in the following 3 ways: |
| |
| #1 ltp_master -f system_file |
| - system_file is an ASCII file containing the list of victim machines. |
| |
| #2 ltp_master system.name.dom.com |
| - space separated names of victim machines. |
| |
| #3 ltp_master |
| - will prompt user for the names of the victim machines. |
| |
| I reccomend using scheme #2, this will help seperate different |
| distros, platforms etc, for example, We might say have a file with RedHat |
| machines, or all SuSE, or all machines of a certain platform (say zSeries). |
| |
| Regardless of how it's invoked ltp_master does the following on each |
| victim machine. |
| |
| - FTP connect to the test system and uploads ltprun |
| - Telnet to each system and kick off ltprun ( runs under nohup ) |
| |
| ltprun script |
| ~~~~~~~~~~~~~ |
| ltprun is where bulk of the automation of ltp is done. |
| It does the following. |
| - downloads the ltp test suite tarfile (ltp.tgz) from ltp_host. |
| - uncompress the test suite and compile it. |
| - runs the test suite. |
| - tars up the results. |
| - uploads results back to ltp_host. |
| |
| In case any of the get, build, run fails, the script will still upload |
| the results back to the ltp_host machine, so you don't have to try to remember |
| which runs were kicked off and correlate that with which runs were reported. |
| |
| ltp_check |
| ~~~~~~~~~ |
| ltp_check lives on the master machine, this script has to be run as root |
| user and it saves the ltp test results in /root/ltp_results. |
| |
| ltp_check does the following; |
| - FTPs to ltp_host and downloads all of the *-ltpoutput.tgz files |
| - Creates a results directory for each machine (using the short |
| hostname) and for each run (based on timestamping) |
| - Uncompresses the gathered result files into the new directory |
| - parses results gathered, saves it as results.out file in the same |
| directory. The results are sorted by system name and then run time. |
| |
| Note: |
| - Check through the scripts for appropriate variables that you may need to |
| change in order to customize further, they should be at the beginning of the |
| file. |
| |
| - This "fire and forget" might not work 100%. But if you find a test |
| (like pth_str02) that hangs you can log in as root and do something like; |
| killall pth_str02 a few times and the test should pick up where it left |
| off. |
| |
| Please send comments or suggestions to: |
| |
| Jay Huie |
| wjhuie@us.ibm.com |
| Linux System Test |
| Phone: 845-435-8164 |