We have a lot of validators for scenarios, but we do not check input arguments. There are two cases: 1) user forget specify some argument; 2) user specify redundant argument In both cases, we will get "TypeError" for each iteration. This validator is not implemented like others, since it doesn't need constructed clients and it looks like more syntax check. Also, this patch fixes one of our samples: samples/tasks/scenarios/dummy/dummy-random-action.[json/yaml] Change-Id: Id3aad571dfc93f8074c724595440979cfd435e2c
Tasks Configuration Samples
To specify your tasks, use configuration files in json or yaml format.
JSON schema of input task format:
:
{
"type": "object",
"$schema": "http://json-schema.org/draft-04/schema",
"patternProperties": {
".*": {
"type": "array",
"items": {
"type": "object",
"properties": {
"args": {
"type": "object"
},
"runner": {
"type": "object",
"properties": {
"type": {"type": "string"}
},
"required": ["type"]
},
"context": {
"type": "object"
},
"sla": {
"type": "object"
},
},
"additionalProperties": False
}
}
}
}
For humans:
- ::
-
- {
-
- "ScenarioClass.scenario_method": [
-
- {
-
- "args": {
-
...
}, "runner": { ... }, "context": { ... }, "sla": { ... }
}
]
}
ScanarioClass should be a subclass of the base Scenario class and scenario_method specifies what benchmark task should be run. Section "args" is also related to scenario. To learn more about scenarios configuration, see samples in samples/tasks/scenarios.
Section "runners" specifies the way, how task should be run. To learn more about runners configurations, see samples in samples/tasks/runners.
Section "context" defines different types of environments in which task can be launched. Look at samples/tasks/contexts for samples.
Section "sla" defines details for determining compliance with contracted values such as maximum error rate or minimum response time. Look at samples/tasks/sla for samples.
See a detailed description of benchmark scenarios, contexts & runners.