Add README.md to integration test crates

iml-system-docker-tests/README.md

@@ -0,0 +1,42 @@
+# IML System Docker Tests
+
+The system level Docker integration tests focus on the creation of various forms of Docker-based lustre filesystems. Vagrant is used to launch the following virtual machines:
+
+1. iscsi - Used for filesystem devices
+1. adm - Where docker will be running
+1. mds[1,2] - The MDS nodes
+1. oss[1,2] - The OSS nodes
+1. c[1-8] - The client nodes
+
+## Installation
+
+Install the following software:
+
+1. cargo
+1. rust
+1. Virtualbox
+1. Vagrant
+
+Once installed, the tests can be run out of the *iml-system-docker-tests* directory. Note that docker is **not** required to be installed on the host as it will be installed on the *adm* virtual machine. For information on testing architecture, please see README.md under *iml-system-test-utils*.
+
+## Running Tests
+
+There are multiple options that can be used when running the tests:
+
+1. Local Install - This method will compile the software and install it on the manager node. While this method takes longer, it will ensure that the manager software is installed off of a local git branch:
+
+ ```bash
+ # To run all tests
+ cargo test -- --test-threads=1 --nocapture 
+ # To run a single test
+ cargo test <test_name> -- --nocapture
+ ```
+
+1. REPO_URI Install - This method is faster and is recommended when the project has been built and is being hosted with an available repo url.
+
+ ```bash
+ # To run all tests
+ REPO_URI=<repo url> cargo test -- --test-threads=1 --nocapture 
+ # To run a single test
+ REPO_URI=<repo url> cargo test <test_name> -- --nocapture
+ ```

iml-system-rpm-tests/README.md

@@ -0,0 +1,42 @@
+# IML System RPM Tests
+
+The system level RPM integration tests focus on the creation of various forms of RPM-based lustre filesystems. Vagrant is used to launch the following virtual machines:
+
+1. iscsi - Used for filesystem devices
+1. adm - The manager node
+1. mds[1,2] - The MDS nodes
+1. oss[1,2] - The OSS nodes
+1. c[1-8] - The client nodes
+
+## Installation
+
+Install the following software:
+
+1. cargo
+1. rust
+1. Virtualbox
+1. Vagrant
+
+Once installed, the tests can be run out of the *iml-system-rpm-tests* directory. For information on testing architecture, please see README.md under *iml-system-test-utils*.
+
+## Running Tests
+
+There are multiple options that can be used when running the tests:
+
+1. Local Install - This method will compile the software and install it on the manager node. While this method takes longer, it will ensure that the manager software is installed off of a local git branch:
+
+ ```bash
+ # To run all tests
+ cargo test -- --test-threads=1 --nocapture 
+ # To run a single test
+ cargo test <test_name> -- --nocapture
+ ```
+
+1. REPO_URI Install - This method is faster and is recommended when the project has been built and is being hosted with an available repo url.
+
+ ```bash
+ # To run all tests
+ REPO_URI=<repo url> cargo test -- --test-threads=1 --nocapture 
+ # To run a single test
+ REPO_URI=<repo url> cargo test <test_name> -- --nocapture
+ ```

iml-system-test-utils/README.md

@@ -0,0 +1,79 @@
+## Integration Testing Overview
+
+The system level tests are broken up into two types:
+
+1. RPM-based integration tests
+1. Docker-based integration tests
+
+Both tests rely on the system level testing architecture described in this document. In general, there are three paths an integration test can take when testing the creation of a lustre filesystem in IML:
+
+1. ldiskfs
+1. zfs
+1. stratagem
+
+For information on how to run the integration tests, see the README.md for both the RPM and Docker system tests.
+
+## Architecture
+
+One of the benefits to using virtual machines is that they provide the ability to take snapshots. These snapshots can be leveraged at different points in time and allow new tests to start closer to their end state, thereby saving time. This approach leads to a di-graph based architecture in which the nodes represent the test states and the weighted edges encapsulate the logic to transition from one state to the next. 
+
+When a test runs the virtual machines will halt at certain times during the progression of the test and snapshots will be taken of each vm. These snapshots will build out the states of the graph. When a new test is invoked, it will parse the snapshot tree and find the snapshot state closest to the tests end state. This state will mark the starting point for the test and the snapshots of the vms will be restored to this point. The test will proceed from this state until it reaches its end state, following its specified path. 
+
+Since a lustre filesystem can be created in multiple ways, tests will naturally be split by their *path*. This path is the key to determine which direction a test will take when going from one node to the next:
+
+```
+ +--------------------+
+ | Init |
+ +--------------------+
+ |
+ | All
+ v
++--------------------------+ Stratagem +--------------------+
+| ImlStratagemConfigured | <----------- | Bare |
++--------------------------+ +--------------------+
+ | |
+ | Stratagem | LdiskfsOrZfs
+ v v
++--------------------------+ +--------------------+
+| StratagemServersDeployed | | ImlConfigured |
++--------------------------+ +--------------------+
+ | |
+ | Stratagem | LdiskfsOrZfs
+ v v
++--------------------------+ +--------------------+ Zfs +--------------+
+| StratagemInstalled | | ServersDeployed | -----> | ZfsInstalled |
++--------------------------+ +--------------------+ +--------------+
+ | | |
+ | Stratagem | Ldiskfs | Zfs
+ v v v
++--------------------------+ +--------------------+ +--------------+
+| StratagemCreated | | LdiskfsInstalled | | ZfsCreated |
++--------------------------+ +--------------------+ +--------------+
+ | | |
+ | | Ldiskfs |
+ | v |
+ | +--------------------+ |
+ | | LdiskfsCreated | |
+ | +--------------------+ |
+ | | |
+ | | All |
+ | v |
+ | All +--------------------+ All |
+ +-------------------------------------> | FilesystemDetected | <--------+
+ +--------------------+ 
+```
+
+The *fs_type* property in the *Config* object indicates if the test will be an ldiskfs or zfs test. The *use_stratagem* property indicates if the test will take the stratagem path. 
+
+## Adding Functionality
+
+The edges of the graph hold the functionality to transition from one state to another. These edges are defined in *snapshots.rs*. To add new functionality to a test, simply add the new state and edge to the snapshots module and make sure that the *Transition* defined in the graph's edge points to the function that will perform the task. If a test's path includes the defined state it will perform the operation defined in the edge. 
+
+## Viewing the current graph
+
+A unit test is provided in *snapshots.rs* that will generate *dot* output of the graph. This dot output can then be piped into graphviz where an image of the graph will be generated. Use the following command to run the test and get the dot output:
+
+```bash
+cargo test test_generate_graph_dot_file -- --nocapture
+```
+