History

Andrey Kurilin 6ed06f974f Deprecate 'command' argument of VMTasks.dd_load_test

VMTasks.dd_load_test appeared as an inheritor of
VMTasks.boot_runcommand_delete scenario with hardcoded script to
execute. Hardcoded script simplifies both user experience (they do not
need to prepare script itself or find it in our samples/source)
maintaining (we can ensure that VMTasks.dd_load_test always launchs the
latest version of ther script).

As like the logic, VMTasks.dd_load_test inherited all the arguments of
the parent which is not convinient when we talk about "command"
argument.

The "command" argument of VMTasks.boot_runcommand_delete is designed to
describe what and how the thing should be executed in the VM. For
example, the can be just a command or script which should be executed.

In VMTasks.dd_load_test we have hardcoded script to execute, so allowing
to setup "command" argument can mislead our customers. But anyway, we
still need to be able setup some part of it.
Despite the fact that we know the interpreter for which our script is
written, the VM can be launched from not trivial image which can use
alternative interpreter (some variety of /bin/sh like /bin/csh in
OpenBSD).

So this patch deprecates 'command' argument and replaces it with
'interpreter' (it defaults to /bin/sh).

Change-Id: Idbf45c71b66e55ce8eb43a6a913f7bf526712a0b

2017-09-28 19:16:29 +03:00

contexts

Add router in context

2017-06-22 14:14:43 +02:00

runners

[Core] Add support for default platform and rally self job

2017-03-27 20:04:14 +03:00

scenarios

Deprecate 'command' argument of VMTasks.dd_load_test

2017-09-28 19:16:29 +03:00

sla

Implement new random name generator for keystone scenarios

2015-10-16 08:00:21 -05:00

support

Fixed shebang and permissions for scripts.

2017-07-03 18:29:30 +05:30

README.rst

Reword samples and setup.cfg

2017-08-03 22:24:56 +00:00

README.rst

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": { ... }

}

]

}

Scenario Plugin should be a subclass of the base Scenario class and implement run() method. 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 scenarios, contexts & runners.