|
5 | 5 | by multiple test workers. |
6 | 6 |
|
7 | 7 | Key concepts: |
8 | | -- **Pool of Instances**: Multiple cluster instances can be running concurrently. Each test worker |
9 | | - requests a cluster instance to run a test on. |
10 | | -- **Coordination via File System**: Workers communicate and coordinate through a system of status |
11 | | - files created on a shared file system. These files act as locks and signals to indicate the |
12 | | - state of cluster instances (e.g., which test is running, if a respin is needed, which |
13 | | - resources are locked). The `status_files` module manages the creation and lookup of these |
14 | | - files. |
15 | | -- **Resource Management**: Tests can declare what resources they need. A resource can be, for |
16 | | - example, a specific feature of a cluster that cannot be used by multiple tests at the same |
17 | | - time. The `ClusterManager` handles locking of these resources so that only one test can use |
18 | | - them at a time. |
19 | | -- **Cluster Respin**: Some tests can modify the state of a cluster in a way that it cannot be |
20 | | - used by subsequent tests. These tests can request a "respin" of the cluster instance, which |
21 | | - re-initializes it to a clean state. |
22 | | -- **`ClusterManager`**: This is the main class that test fixtures interact with. Its `get()` |
23 | | - method is used to acquire a suitable cluster instance for a test, taking into account available |
24 | | - instances, resource requirements, and scheduling priority. |
| 8 | + - **Pool of Instances**: Multiple cluster instances can be running concurrently. Each test worker |
| 9 | + requests a cluster instance to run a test on. |
| 10 | + - **Coordination via File System**: Workers communicate and coordinate through a system of status |
| 11 | + files created on a shared file system. These files act as locks and signals to indicate the |
| 12 | + state of cluster instances (e.g., which test is running, if a respin is needed, which |
| 13 | + resources are locked). The `status_files` module manages the creation and lookup of these |
| 14 | + files. |
| 15 | + - **Resource Management**: Tests can declare what resources they need. A resource can be, for |
| 16 | + example, a specific feature of a cluster that cannot be used by multiple tests at the same |
| 17 | + time. The `ClusterManager` handles locking of these resources so that only one test can use |
| 18 | + them at a time. |
| 19 | + - **Cluster Respin**: Some tests can modify the state of a cluster in a way that it cannot be |
| 20 | + used by subsequent tests. These tests can request a "respin" of the cluster instance, which |
| 21 | + re-initializes it to a clean state. |
| 22 | + - **`ClusterManager`**: This is the main class that test fixtures interact with. Its `get()` |
| 23 | + method is used to acquire a suitable cluster instance for a test, taking into account available |
| 24 | + instances, resource requirements, and scheduling priority. |
25 | 25 |
|
26 | 26 | This system allows for efficient parallel execution of tests that require a running Cardano |
27 | 27 | cluster, by reusing cluster instances and managing contention for shared resources. |
|
0 commit comments