Difference between revisions of "Rally/Concepts"
(Contexts) |
(Subheads) |
||
| Line 9: | Line 9: | ||
=== Contexts === | === Contexts === | ||
| + | ==== Notion of contexts ==== | ||
'''''The notion of contexts''''' in Rally is essentially used to define different types of '''''environments''''' in which benchmark scenarios will be launched. Those environments are usually specified by such parameters as the number of '''''tenants and users''''' that should be present in an OpenStack project, the '''''roles''''' granted to those users, extended or narrowed '''''quotas''''' and so on. | '''''The notion of contexts''''' in Rally is essentially used to define different types of '''''environments''''' in which benchmark scenarios will be launched. Those environments are usually specified by such parameters as the number of '''''tenants and users''''' that should be present in an OpenStack project, the '''''roles''''' granted to those users, extended or narrowed '''''quotas''''' and so on. | ||
| + | |||
| + | ==== User's view ==== | ||
'''''In user's view''''', contexts in Rally are manageable via the '''''task configuration files'''''. In a typical configuration file, each benchmark scenario to be run has is not only supplied by the information on with which arguments and how many times it should be launched, but also with a special '''''"context"''''' field. In this field, the user may configure a number of contexts he needs his scenarios to be run within. | '''''In user's view''''', contexts in Rally are manageable via the '''''task configuration files'''''. In a typical configuration file, each benchmark scenario to be run has is not only supplied by the information on with which arguments and how many times it should be launched, but also with a special '''''"context"''''' field. In this field, the user may configure a number of contexts he needs his scenarios to be run within. | ||
| Line 43: | Line 46: | ||
} | } | ||
</pre> | </pre> | ||
| + | |||
| + | |||
| + | ==== Developer's view ==== | ||
'''''In developer's view''''', contexts management is implemented via '''''Context classes'''''. Each context type that can be specified in the task configuration file corresponds to a certain subclass of the base ''Context'' class, located in the ''rally.benchmark.context'' module. Every context class should implement a fairly simple interface: | '''''In developer's view''''', contexts management is implemented via '''''Context classes'''''. Each context type that can be specified in the task configuration file corresponds to a certain subclass of the base ''Context'' class, located in the ''rally.benchmark.context'' module. Every context class should implement a fairly simple interface: | ||
Revision as of 13:09, 21 May 2014
Contents
Main concepts - Developer's view
This article describes in detail several main design concepts used throughout the Rally code (such as benchmark scenarios, contexts etc.). A good understanding of these concepts might be essential for a successful contribution to Rally.
Benchmark scenarios
Under construction
Contexts
Notion of contexts
The notion of contexts in Rally is essentially used to define different types of environments in which benchmark scenarios will be launched. Those environments are usually specified by such parameters as the number of tenants and users that should be present in an OpenStack project, the roles granted to those users, extended or narrowed quotas and so on.
User's view
In user's view, contexts in Rally are manageable via the task configuration files. In a typical configuration file, each benchmark scenario to be run has is not only supplied by the information on with which arguments and how many times it should be launched, but also with a special "context" field. In this field, the user may configure a number of contexts he needs his scenarios to be run within.
In the example below, the "users" context specifies that the "NovaServers.boot_server" scenario should be run from 1 tenant having 3 users in it. Bearing in mind that the default quota for the number of instances is 10 instances pro tenant, it is also reasonable to extend it to, say, 20 in the "quotas" context. Otherwise the scenario would eventually fail, since it tries to boot a server 15 times from a single tenant.
{
"NovaServers.boot_server": [
{
"args": {
"flavor_id": 42,
"image_id": "73257560-c59b-4275-a1ec-ab140e5b9979"
},
"runner": {
"type": "constant",
"times": 15,
"concurrency": 2
},
"context": {
"users": {
"tenants": 1,
"users_per_tenant": 3
},
"quotas": {
"nova": {
"instances": 20
}
}
}
}
]
}
Developer's view
In developer's view, contexts management is implemented via Context classes. Each context type that can be specified in the task configuration file corresponds to a certain subclass of the base Context class, located in the rally.benchmark.context module. Every context class should implement a fairly simple interface:
