Goals
- Test LNet via the Dynamic LNet Configuration interface
- Provide an easy to use and expandable infrastructure to create and add test scripts
- Provide a method to easily parse results and understand the health of the LNet Code.
Background and strategic fit
Currently there exists very little testing for LNet. With the expected LNet features to be added in the future, it is important to be able to test LNet as thoroughly as possible, as well as be able to regression test existing functionality. The LUTF fulfills that need.
Overview
The LUTF provides a master/slave work flow. The LUTF Master is deployed on one node and the Agents are deployed on the test nodes. The master controls the agent by directing them to execute python tests scripts. The master manages the interactions between the different LUTF agents.
Each agent collects the result from the test script and transfers it to the master. The master parses and summarizes the results in a YAML file.
The LUTF provides infrastructure for the test scripts to pull information about the different nodes on which the agent runs. This way the script writer only concentrates on writing testing logic, rather than writing code to run the test scripts or collect results. It also provides an abstraction layer, so that the scripts don't need to have prior knowlege of the nodes the tests will run on.
Requirements
Interface Requirements
| ID | Status | Class | Description |
|---|---|---|---|
The LUTF shall provide an integrated python interpreter | |||
| The LUTF shall support python 2.7.5 | |||
| The LUTF shall use SWIG to create the interface between the python front end and the C back end. | |||
| The LUTF shall allow the execution of python scripts within the LUTF environment | |||
| The LUTF shall provide an API to run scripts on the test nodes on which the Agent runs | |||
The LUTF shall provide a synchronization mechanism to enable a script running on master to synchronize between the different Agents. EX: A test could require configuring nodes, then running traffic, then changing configuration on one of the nodes, then running traffic again. Such a test would require synchronization | |||
| The LUTF shall provide infrastructure to create and mount a Luster file system. | |||
| The LUTF shall provide a mechanism to collect test results from the Agents | |||
| The LUTF shall provide the results of a test run in YAML format | |||
| The LUTF shall provide infrastructure to run a suite of tests and collect results on all the test runs | |||
| The LUTF shall provide a set of parameters, which the AT can use to provide information on the available test nodes | |||
| The LUTF shall provide infrastructure to deploy and run the LUTF master and LUTF Agents on the test nodes | |||
| The LUTF shall provide infrastructure to run the available test suites. | |||
| The LUTF YAML format shall be provided to Maloo to be parsed and displayed. | |||
| The LUTF shall require the all test nodes be setup with passwordless ssh. | |||
| The LUTF shall be integrated in the existing Lustre tests | |||
| The LUTF shall be packaged in the lustre test rpm | |||
| The LUTF shall provide a method to generate test documentation for the test scripts provided. |
LUTF Master Requirements
| ID | Status | Class | Description |
|---|---|---|---|
| The LUTF master shall provide an API to query the management IP address of the test nodes on which the Agent runs | |||
| The LUTF master shall provide an API to query all available interfaces on the tests nodes on which the Agent runs | |||
| The LUTF master shall monitor the heartbeat of each Agent and report if an agent died. | |||
| The LUTF master shall collect core information if a node crashes. |
LUTF Agent Requirements
| ID | Status | Class | Description |
|---|---|---|---|
| The LUTF agent shall execute scripts passed in by the agent | |||
| The LUTF agent shall report back the results to the master in YAML formate | |||
| The LUTF shall capture all console output and include that in the results file. |