Introduction

Currently there is no dedicated functional test tool in Lustre test suites for LNet testing. Lustre Unit Test Framework (LUTF) fills that gap to provide a means for testing existing LNet features as well as new features that would be added in future. It facilitates an easy way of adding new test cases/scripts to test any new LNet feature.

Objectives 

This High Level Design Document describes the current LUTF design, code base, infrastructure requirements for its setup and the new features that can be added on top of the current design.

Reference Documents

Document Structure

This document is made up of the following sections:

• Design Overview
• Building the LUTF
• LUTF-Autotest Integration
• Infrastructure

LUTF Design Overview

The LUTF is designed with a Master-Agent approach to test LNet. The Master and Agent LUTF instance uses a telnet python module to communicate with each other and more than one Agent can communicate with single Master instance at the same time. The Master instance controls the execution of the python test scripts to test LNet on Agent instances. It collects the results of all the tests run on Agents and write them to a YAML file. It also controls the synchronization mechanism between test-scripts running on different Agents.

The below diagram shows how LUTF interacts with LNet

Figure 1: System Level Diagram

Building the LUTF

The LUTF shall be integrated with the Lustre tests under lustre/tests/lutf. The LUTF will be built and packaged with the standard

sh ./autogen.sh
./configure --with-linux=<kernel path>
make
# optionally
make rpms
# optionally
make install

The make system will build the following items:

1. lutf binary
2. liblutf_agent.so - shared library to communicate with the LUTF backend.
3. clutf_agen.py and clutf_agent.so: glue code that allows python to call functions in liblutf_agent.so
4. _lnetconfig.so and lnetconfig.py - glue code to allow python test scripts to utilize the DLC interface.

The build process will check if python 2.7.5 and SWIG 2.0 or higher is installed before building. If these requirements are not met the LUTF is not built

If the LUTF is built it will be packaged in the lustre-tests rpm and installed in /usr/lib64/lustre/tests/lutf.

Test Environment Set-Up

Each node which will run the LUTF will need to have the following installed

1. ncurses library

   1. yum install ncurses-devel

2. readline library

   1. yum install readline-devel

3. python 2.7.5

   1. https://www.python.org/download/releases/2.7.5/

   2. ./configure --prefix=<> --enable-shared # it is recommended to install in standard system path

   3. make; make install

4. setuptools
   1. https://pypi.python.org/pypi/setuptools
      
   2. The way it worked for me:
      1. Download package and untar

      2. python2.7 setup.py install

5. psutils
   1. https://pypi.python.org/pypi?:action=display&name=psutil
      
      1. untar
      2. cd to untared directory
      3. python2.7 setup.py install
6. netifaces
   1. https://pypi.python.org/pypi/netifaces
      
7. Install PyYAML

The LUTF will also require that passwordless ssh is setup for all the nodes which run the LUTF.

LUTF/AT Integration

LUTF Deployment

The LUTF will provide a deployment script, lutf_deploy.py, which will download and install all the necessary elements defined above. If everything is successful it will start the LUTF given the LUTF YAML configuration file, described later.

AT Integration

A similar script to auster will be provided by the LUTF, lutf_engage.py. The purpose of the script is to manage which nodes the LUTF will be deployed on. Only the AT has knowledge of the nodes available; therefore the script will perform the following steps;

1. Take as input the following parameters. NOTE: These parameters can be provided as a set of environment variables, or can be placed in a YAML file and then the path of the YAML file can be passed to the lutf_engage.py script. The second option will be assumed in this HLD.
   
   1. IP address of node to be used for master
   2. IP addresses of nodes to be used as agents
   3. Two YAML configuration files for the Master and Agent nodes.
   4. YAML configuration file describing the tests to run.
2. Call the lutf_deploy.py script for each of the nodes provided. It will pass the Master YAML LUTF Configuration file to the master node that the agent configuration file to the agent nodes.
   1. Query the LUTF master to ensure the expected number of agents are connected.
   2. If everything is correct, then continue with the tests, otherwise build a YAML block describing the error.
3. Send the test YAML configuration file to the LUTF master and wait.
4. Once the tests are completed the LUTF master will return a YAML block describing the test results, described below
   1. the LUTF Master will provide an API based around paramiko. The API is described below.

LUTF Configuration Files

Master YAML Configuration File

This configuration file describes the information the master needs in order to start

config:
   type: master
   mport: <master port>
   base_path: <base path to the LUTF directory - optional.
               if not present default to /usr/lib64/lustre/tests>
   extra_py: <extra python paths>

Slave YAML Configuration File

This configuration file describes the information the agent needs in order to start

config:
   type: agent
   maddress: <master address - optional>
   mport: <master port>
   dport: <agent daemon port>
   base_path: <base path to the LUTF directory>
   extra_py: <extra python paths>

Test YAML Configuration File

This configuration file describes the list of tests to run

config:
   type: tests
   tests:
      - 0: <test set name>
        1: <test set name>
        2: <test set name>
        ....
        N: <test set name>

LUTF Result file

This YAML result file describes the results of the tests that were requested to run

TestGroup:
    test_group: review-ldiskfs
    testhost: trevis-13vm5
    submission: Mon May  8 15:54:41 UTC 2017
    user_name: root
autotest_result_group_id: 5e11dc5b-7dd7-48a1-b4a3-74a333acd912
test_sequence: 1
test_index: 10
session_group_id: cfeff6b3-60fc-438a-88ef-68e65a08694f
enforcing: true
triggering_build_number: 45090
triggering_job_name: lustre-reviews
total_enforcing_sessions: 5
code_review:
 type: Gerrit
 url: review.whamcloud.com
 project: fs/lustre-release
 branch: multi-rail
 identifiers:
 - id: 3fbd25eb0fe90e4f34e36bad006c73d756ef8499
issue_tracker:
 type: Jira
 url: jira.hpdd.intel.com
 identifiers:
 - id: LU-9119
Tests:
- name: dlc
        description: lutf dlc
        submission: Mon May  8 15:54:43 UTC 2017
        report_version: 2
        result_path: lustre-release/lustre/tests/lutf/python/tests/
        SubTests:
        - name: test_01
          status: PASS
          duration: 2
          return_code: 0
          error:
        - name: test_02
          status: PASS
          duration: 2
          return_code: 0
          error:
        duration: 5
        status: PASS
-  name: multi-rail
        description: lutf multi-rail
        submission: Mon May  8 15:59:43 UTC 2017
        report_version: 2
        result_path: lustre-release/lustre/tests/lutf/python/tests/
        SubTests:
        - name: test_01
            status: PASS
            duration: 2
            return_code: 0
            error:
        - name: test_02
            status: PASS
            duration: 2
            return_code: 0
            error:
        duration: 5
        status: PASS

Collect Results

1. A YAML format is decided for the results of the entire test-run and a result YAML file is generated per that format.
2. The YAML file also points to the path where the test result file for each test is stored.
3. This YAML file is then passed to AT which further passes it to Maloo.
   
   

Network Interface Discovery

The LUTF test scripts will need to be implemented in a generic way. Which means that each test scripts which requires the use of interfaces, will need to discover the interfaces available to it on the node. If there are sufficient number of interfaces of the correct type, then the test can continue otherwise the test will be skipped and reported as such in the final result.

 Maloo

1. A separate section is to be created in Maloo to display LUTF test results.
2. The results from output YAML file passed from AT are displayed in the LUTF results section.
3. A Test-parameter specifically for LUTF tests to be defined that will allow to run only LUTF tests. This will help in avoiding unnecessary tests to run for only LNet related changes.

C Backend

This allows for the setup of TCP connection (TCP sockets) to connect the Master and Agent nodes (lutf.c).  LUTF can be run on a node in either Master mode or an Agent mode. 

1. Master mode:

   1. Spawns a listener thread (lutf_listener_main) to listen to Agent connections (lutf.c).

   2. Maintains a list of the Agents, check on the health of Agents, associate and disassociate with Agents (liblutf_agent.c).
   3. Start up a python interpreter (lutf_python.c).

2. Agent mode:

   1. Spawns a heart beat thread (lutf_heartbeat_main) to send a heart beat  to master every 2 seconds. The master uses this Heart beat signal to determine the aliveness of the agents (lutf.c).
   2. Start up a python interpreter (lutf_python.c).

Python

Script execution and result collection

1. A telnet connection is established from Master to Agent when we create a Script instance by running lutf_script.Script('local_intf',  'script_path ',  'output_dir')  (lutf_script.py).
2. The scripts from 'script_path' in lutf_script.Script('local_intf',  'script_path ',  'output_dir') are copied over to Agent using scp (lutf_agent_ctrl.py).
3. The copied scripts are then executed by calling run_script() on the Script instance created. (lutf_agent_ctrl.py).
4. If an 'output_dir' path is specified then the results of the script execution are copied to the path given by calling push_results(). If no path is provided for the 'output_dir' then the results are ignored.

Improvements

1. Currently the LUTF is designed to have the Python infrastructure establish a Telnet connection to facilitate Master to scp the test scripts to Agent and then execute those test scripts. The Telnet approach can be improved upon by using SSH instead. 
2. A synchronization mechanism can be added to synchronize the different parts of one test script running on different Agents by providing an API that uses notification mechanism. The Master node will control this synchronization between different Agent nodes that are used for running a test script. An example scenario of how it would be implemented is -If a test script is such that it requires to do some operation on more than one Agent node, then as one part of a test script runs to it completion on one Agent, it would notify the Master about its status by calling this API and then Master can redirect this event to the main script waiting on it which will trigger the other part (operation) to start execution on another Agent node.

Batch test 

1. All the similar test scripts (pertaining to one feature like multi-rail or Dynamic Discovery) are bundled in one auto-test script which when executed, runs all the test-scripts listed in it and then post the cumulative results after execution. 

2. There is an auto-test script for each of the bundle of test-scripts related to one feature.

3. The result file for each individual test script is also placed in lutfTMP directory on Agent node.

Improvements

1. The above design can be changed to have all the test scripts related to a feature placed in separate directory under LUTF/python/tests/ and then have single auto-test script which will trigger the execution of all the test scripts under one folder. The name of the folder can be passed as a parameter to this auto-test script.