| Item | Notes |
|---|
| Work for config | - Lee suggested to modify the AT class structure to have a parent configuration class, the lustre configuration class inherits from it, then we can add one specific for the LUTF.
- This will help to customize the operation for the LUTF
- including monitoring the progress of the test
- The timeline we'd be looking at is prior to the 2.12 release, which gives enough time to make the above change.
|
| Creating a YAML file instead of setting environment variables | - The AT has many configuration scripts. So one specific for the LUTF can be written, which creates a setup YAML file to pass to the script
- The setup YAML file will define the result_dir: The directory where to put all the results file
|
| The location of the script to execute | - The LUTF is now integrated in the Lustre build. Specifically the test RPM. So when that gets installed on the node, then all the LUTF will be installed as well
- Path to the installation is:
/usr/lib64/lustre/tests/lutf - The script that the AT should run will be under: /usr/lib64/lustre/tests/lutf/python
- Since we're creating a new AT config script for the LUTF the path can be set there.
|
| cluster to run | - The multi-rail scripts need nodes (VMs) with multiple interfaces
- OUTSTANDING: We still don't know how much work it is to create those VMs and make them a part of the AT test resources.
- We said that this is a separate work item from integrating the LUTF into the AT, since there are LUTF scripts that can run with one interface.
|
| The name of the file the AT monitors for test progress | - We said that with the AT sub-class for the LUTF we can customize how the AT monitors progress
- Amir to give a proposal on how to monitor the LUTF test progress.
|
| Displaying the results on Maloo | - Amir to propose a format to display the results on Maloo
- Will probably try to stick to how it's currently displayed to minimize the amount of work.
|