Table of Contents

Contents

  1. Table of Contents
  2. Components
  3. Setup
    1. Conmux (Optional)
    2. Directory Structure
    3. Bootloader
    4. kernel config
  4. monitor_queue
  5. start_all_queues
  6. mirror

Components

An AutoTest scheduling server uses a few different scripts to accomplish its task.

Setup

First, a machine must be designated as the test server. Configure the test server with the following directory structure.

Conmux (Optional)

In some cases tests will build and execute kernels that run but leave the machine unreachable via SSH. The machine must be rebooted. Conmux/Howto can be used to do this remotely.

Directory Structure

Example Directory structure:

Most users will probably prefer just to have the queue name match the hostname of the client they wish to run tests on. This simplifies debugging and the resulting output. For initial setup this is definitely the best way to get started.

Plain AutoTest control files can be placed in control_files. A control file for a basic set of tests to happen on each release could might look like (/home/autotest/control_files/basic-tests) 

   1 job.run_test('kernbench', 2)
   2 job.run_test('dbench')
   3 job.run_test('tbench')
   4 job.run_test('reaim')
   5 job.run_test('fsx')
   6 job.run_test('bonnie')

see the AutoTest documentation for more details.

You can also put server-side control files in the queue - just end the control-file name with ".srv"

Along with that goes a mapping file describing which control files to run when a new kernel release is found by the mirror script. Here is a sample mapping (/home/autotest/control_files/mirror_clients) 

x86_64 /home/testing/control_files/basic-tests /home/testing/control_files/another-test-to-run-too
sparc /home/testing/control_files/basic-tests
lonehost.someplace.net /home/testing/control_files/advanced-tests

This mapping file tells the mirror script to run the tests in basic-tests on the machines in /home/testing/queue/x86_64/.machines and /home/testing/queue/sparc/.machines and also run advanced-tests on lonehost.someplace.net. The script also supports specifying a kernel config file for each machine or queue using the -f flag and a format identical to the clients config file except if multiple configs are specified for a single machine only the first one will be used.

Bootloader

Note: If you are going to get hung up somewhere this is probably one of the places it'll happen.

See the notes in Autoserv about the bootloader if you are having problems with autoserv stalling or with machines not booting the correct kernel.

kernel config

Currently when the AutoTest fragments are wrapped with code to compile, install, and boot a kernel by version string it simply tries to use a kernel config file located at /boot/config on the client machine. See detail of the mirror script if you need to override this location on a per machine basis.

monitor_queue

monitor_queue <spool_directory> <resultsdir> [conmux_server]

This is a daemon that simply watches a directory for new AutoTest control files (or Autoserv, if they end in .srv). When it finds a control file it automatically launches them on a set of machines. The machines to run the control files on are specified in one of two ways: 1) the spool_directory itself is the name of a host or 2) the spool_directory contains a newline separated file (spool_directory/.machines) containing a list of machines. monitor_queue logs to spool_directory/.log as it executes control files.

If a group queue only has one machine then AutoTest control files placed in the queue will have the results placed in resultsdir in a directory with the same name as the control file. If such a directory already exists monitor_queue will add a timestamp to the name. If multiple machines are specified and the control file is an AutoTest file the results directory will be named in the same way but there will be an additional directory inside for each machine on which the control file was run. Note the machines will run the AutoTest control file in parallel (on all machines in the group at the same time) using this mode.

Finally, if a control file is found that has a .srv extension it will execute it as an Autoserv file and will pass the list of machines in the queue group (the list of machines in the .machines file) in as a list variable called 'machines'. The Autoserv file has full control and can do whatever it like with respect to results directories, etc.

start_all_queues

start_all_queues <top_level_dir>

This is a simple script that just launches several monitor_queue instances at once. It simply scans top_level_dir/queue and for each dir in it it invokes monitor_queue queue/dir results. For the example directory structure given above one would run start_all_queues /home/testing and a monitor_queue instance would be created for each queue with the results directed into /home/testing/results.

mirror

mirror [-c CLIENTS] [-f CONFIGS] [-e EMAIL] <mirrordir> <queuedir>

When run this will rsync all kernel releases from kernel.org into mirrordir. For each kernel release that was not in mirrordir and was just pulled from kernel.org it will perform actions based on a mapping file (which defaults to $HOME/.autotest_mirror_clients or can be overridden with -c). Additionally, if an email address is specified it will notify the comma separated list of email addresses informing them which new releases were mirrored.

The mapping file is a newline separated dictionary of lists. The first element is a queuename which corresponds to the path queuedir/queuename. The remaining elements are absolute paths of control files to have that queue execute for each new kernel release. The simple AutoTest control file will be wrapped with enough AutoTest code to have it automatically compile and boot the newly released kernel. Once booted the tests from the mapping specified control file will be performed.

If the mapping specifies a control file with a .srv extension is will simply append a preamble to the .srv file and queue it with a new name. This allows extremely flexible autoserv files to be run in response to kernel releases. The preamble simply consists of the definition of three variables kernel, config, and patches. kernel is a string kernel version (i.e. 2.6.23-rc6-git3), config is pulled from the mapping file or /boot/config, and patches is a string list of patches to apply to the kernel.

An additional mapping file can be specified which specifies a remote path to a kernel config file for that host. If a host doesn't have an entry in the specified conf file or the file is missing /boot/config is always assumed.

Scheduler (last edited 2007-09-29 19:55:50 by MartinBligh)