| Target release | Release name or number |
|---|---|
| Epic | Link to related JIRA epic or feature |
| Document status | |
| Document owner | |
| Designer | Lead designer |
| Developers | Lead developer |
| QA | Lead tester |
|
Currently the facilities provided by lnet_selftest do not allow the flexibility of defining the call flows for the different tests. In effect the call flow is hardcoded in the test tool itself. This does not provide the flexibility of testing different types of call flows that might be problematic. Also the current call flows do not reflect how the lustre filesystem actually uses the LNet API through the PTLRPC layer.
Why are you doing this? How does this relate to your overall product strategy?
| ID | Status | Class | Description |
|---|---|---|---|
| Specify the LNet message flow through an easy syntax | ||
| Specify the number of times the flow should be repeated | ||
| Specify the length of time the flow should run for. This method takes precedence over the above | |||
| Specify whether to stop test on first failure or to count and continue | ||
| Specify an error flow that can be injected randomly in the standard call flow already defined. |
Include any mockups, diagrams or visual designs relating to these requirements.
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
| (e.g. How we make users more aware of this feature?) | Communicate the decision reached |