Creates constant load executing a scenario a specified number of times.
This runner will place a constant load on the cloud under test by executing each scenario iteration without pausing between iterations up to the number of times specified in the scenario config.
The concurrency parameter of the scenario config controls the number of concurrent scenarios which execute during a single iteration in order to simulate the activities of multiple users placing load on the cloud under test.
Namespace: default
Creates constant load executing a scenario for an interval of time.
This runner will place a constant load on the cloud under test by executing each scenario iteration without pausing between iterations until a specified interval of time has elapsed.
The concurrency parameter of the scenario config controls the number of concurrent scenarios which execute during a single iteration in order to simulate the activities of multiple users placing load on the cloud under test.
Namespace: default
Scenario runner that does the job with specified frequency.
Every single benchmark scenario iteration is executed with specified frequency (runs per second) in a pool of processes. The scenario will be launched for a fixed number of times in total (specified in the config).
An example of a rps scenario is booting 1 VM per second. This execution type is thus very helpful in understanding the maximal load that a certain cloud can handle.
Namespace: default
Module: rally.plugins.common.runners.rps
Scenario runner that executes benchmark scenarios serially.
Unlike scenario runners that execute in parallel, the serial scenario runner executes scenarios one-by-one in the same python interpreter process as Rally. This allows you to benchmark your scenario without introducing any concurrent operations as well as interactively debug the scenario from the same command that you use to start Rally.
Namespace: default
Maximum average duration of one iterations atomic actions in seconds.
Namespace: default
Module: rally.plugins.common.sla.max_average_duration_per_atomic
Limit the number of outliers (iterations that take too much time).
The outliers are detected automatically using the computation of the mean and standard deviation (std) of the data.
Namespace: default
Calculates perfomance degradation based on iteration time
This SLA plugin finds minimum and maximum duration of iterations completed without errors during Rally task execution. Assuming that minimum duration is 100%, it calculates performance degradation against maximum duration.
Namespace: default
Context class for generating temporary users/tenants for benchmarks.
Namespace: default
This context supports using existing users in Rally.
It uses information about deployment to properly initialize context["users"] and context["tenants"]
So there won't be big difference between usage of "users" and "existing_users" context.
Namespace: default
Module: rally.plugins.openstack.context.keystone.existing_users
Context for specifying OpenStack clients versions and service types.
Some OpenStack services support several API versions. To recognize the endpoints of each version, separate service types are provided in Keystone service catalog.
Rally has the map of default service names - service types. But since service type is an entity, which can be configured manually by admin( via keystone api) without relation to service name, such map can be insufficient.
Also, Keystone service catalog does not provide a map types to name (this statement is true for keystone < 3.3 ).
This context was designed for not-default service types and not-default API versions usage.
An example of specifying API version:
# In this example we will launch NovaKeypair.create_and_list_keypairs
# scenario on 2.2 api version.
{
"NovaKeypair.create_and_list_keypairs": [
{
"args": {
"key_type": "x509"
},
"runner": {
"type": "constant",
"times": 10,
"concurrency": 2
},
"context": {
"users": {
"tenants": 3,
"users_per_tenant": 2
},
"api_versions": {
"nova": {
"version": 2.2
}
}
}
}
]
}
An example of specifying API version along with service type:
# In this example we will launch CinderVolumes.create_and_attach_volume
# scenario on Cinder V2
{
"CinderVolumes.create_and_attach_volume": [
{
"args": {
"size": 10,
"image": {
"name": "^cirros.*uec$"
},
"flavor": {
"name": "m1.tiny"
},
"create_volume_params": {
"availability_zone": "nova"
}
},
"runner": {
"type": "constant",
"times": 5,
"concurrency": 1
},
"context": {
"users": {
"tenants": 2,
"users_per_tenant": 2
},
"api_versions": {
"cinder": {
"version": 2,
"service_type": "volumev2"
}
}
}
}
]
}
Also, it possible to use service name as an identifier of service endpoint, but an admin user is required (Keystone can return map of service names - types, but such API is permitted only for admin). An example:
# Similar to the previous example, but `service_name` argument is used
# instead of `service_type`
{
"CinderVolumes.create_and_attach_volume": [
{
"args": {
"size": 10,
"image": {
"name": "^cirros.*uec$"
},
"flavor": {
"name": "m1.tiny"
},
"create_volume_params": {
"availability_zone": "nova"
}
},
"runner": {
"type": "constant",
"times": 5,
"concurrency": 1
},
"context": {
"users": {
"tenants": 2,
"users_per_tenant": 2
},
"api_versions": {
"cinder": {
"version": 2,
"service_name": "cinderv2"
}
}
}
}
]
}
Namespace: default
Context for creating samples and collecting resources for benchmarks.
Namespace: default
Context class for create stack by given template.
This context will create stacks by given template for each tenant and add details to context. Following details will be added:
id of stack; template file contents; files dictionary; stack parameters;
Heat template should define a "gate" node which will interact with Rally by ssh and workload nodes by any protocol. To make this possible heat template should accept the following parameters:
network_id: id of public network router_id: id of external router to connect "gate" node key_name: name of nova ssh keypair to use for "gate" node
Namespace: default
Context class for adding temporary servers for benchmarks.
Servers are added for each tenant.
Namespace: default
Context class for create temporary stacks with resources.
Stack generator allows to generate arbitrary number of stacks for each tenant before test scenarios. In addition, it allows to define number of resources (namely OS::Heat::RandomString) that will be created inside each stack. After test execution the stacks will be automatically removed from heat.
Namespace: default
Context class for generating temporary cluster model for benchmarks.
Namespace: default
Module: rally.plugins.openstack.context.magnum.cluster_templates
Context class for generating temporary cluster for benchmarks.
Namespace: default
This context creates 'security services' for Manila project.
Namespace: default
Module: rally.plugins.openstack.context.manila.manila_security_services
Context class for creating murano environments.
Namespace: default
Module: rally.plugins.openstack.context.murano.murano_environments
Context class for uploading applications for murano.
Namespace: default
Module: rally.plugins.openstack.context.murano.murano_packages
This context supports using existing networks in Rally.
This context should be used on a deployment with existing users.
Namespace: default
Module: rally.plugins.openstack.context.network.existing_network
Create networking resources.
This creates networks for all tenants, and optionally creates another resources like subnets and routers.
Namespace: default
Namespace: default
Module: rally.plugins.openstack.context.not_for_production.tempest
Context class for adding temporary servers for benchmarks.
Servers are added for each tenant.
Namespace: default
Context class for setting up the Cluster an EDP job.
Namespace: default
Module: rally.plugins.openstack.context.sahara.sahara_cluster
Context class for setting up Input Data Sources for an EDP job.
Namespace: default
Module: rally.plugins.openstack.context.sahara.sahara_input_data_sources
Context class for setting up Job Binaries for an EDP job.
Namespace: default
Module: rally.plugins.openstack.context.sahara.sahara_job_binaries
Context class for setting up Output Data Sources for an EDP job.
Namespace: default
Module: rally.plugins.openstack.context.sahara.sahara_output_data_sources
Base class for the contexts providing customized image with.
Every context class for the specific customization must implement the method _customize_image that is able to connect to the server using SSH and e.g. install applications inside it.
This is used e.g. to install the benchmark application using SSH access.
This base context class provides a way to prepare an image with custom preinstalled applications. Basically, this code boots a VM, calls the _customize_image and then snapshots the VM disk, removing the VM afterwards. The image UUID is stored in the user["custom_image"]["id"] and can be used afterwards by scenario.
Namespace: default
Context class for generating image customized by a command execution.
Run a command specified by configuration to prepare image.
Use this script e.g. to download and install something.
Namespace: default
Module: rally.plugins.openstack.context.vm.image_command_customizer
Context class for adding temporary audit template for benchmarks.
Namespace: default
Module: rally.plugins.openstack.context.watcher.audit_templates
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
scenario for create and list aggregate.
Namespace: default
Scenario for create and delete aggregate.
Namespace: default
Namespace: default
Module: rally.plugins.openstack.scenarios.nova.availability_zones
Namespace: default
Namespace: default
Namespace: default
Scenario for create and get flavor.
Namespace: default
Namespace: default
Module: rally.plugins.openstack.scenarios.nova.floating_ips_bulk
Namespace: default
Module: rally.plugins.openstack.scenarios.nova.floating_ips_bulk
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Module: rally.plugins.openstack.scenarios.nova.security_group
Namespace: default
Module: rally.plugins.openstack.scenarios.nova.security_group
Namespace: default
Module: rally.plugins.openstack.scenarios.nova.security_group
Namespace: default
Module: rally.plugins.openstack.scenarios.nova.security_group
"Benchmark scenarios for Nova FloatingIp API.
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Module: rally.plugins.openstack.scenarios.ceilometer.queries
Namespace: default
Module: rally.plugins.openstack.scenarios.ceilometer.queries
Namespace: default
Module: rally.plugins.openstack.scenarios.ceilometer.queries
Namespace: default
Module: rally.plugins.openstack.scenarios.ceilometer.resources
Namespace: default
Module: rally.plugins.openstack.scenarios.ceilometer.resources
Namespace: default
Module: rally.plugins.openstack.scenarios.ceilometer.resources
Namespace: default
Module: rally.plugins.openstack.scenarios.ceilometer.samples
Namespace: default
Module: rally.plugins.openstack.scenarios.ceilometer.samples
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Module: rally.plugins.openstack.scenarios.magnum.cluster_templates
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Module: rally.plugins.openstack.scenarios.murano.environments
Namespace: default
Module: rally.plugins.openstack.scenarios.murano.environments
Namespace: default
Module: rally.plugins.openstack.scenarios.murano.environments
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Module: rally.plugins.openstack.scenarios.authenticate.authenticate
Namespace: default
Module: rally.plugins.openstack.scenarios.authenticate.authenticate
Namespace: default
Module: rally.plugins.openstack.scenarios.authenticate.authenticate
Namespace: default
Module: rally.plugins.openstack.scenarios.authenticate.authenticate
Namespace: default
Module: rally.plugins.openstack.scenarios.authenticate.authenticate
Namespace: default
Module: rally.plugins.openstack.scenarios.authenticate.authenticate
Namespace: default
Module: rally.plugins.openstack.scenarios.authenticate.authenticate
Namespace: default
Module: rally.plugins.openstack.scenarios.authenticate.authenticate
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.loadbalancer_v1
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.loadbalancer_v1
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.loadbalancer_v1
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.loadbalancer_v1
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.loadbalancer_v1
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.loadbalancer_v1
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.loadbalancer_v1
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.loadbalancer_v1
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.loadbalancer_v1
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.security_groups
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.security_groups
Namespace: default
Module: rally.plugins.openstack.scenarios.neutron.security_groups
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Randomly throw exceptions in atomic actions.
Namespace: default
Namespace: default
Namespace: default
Namespace: default
Module: rally.plugins.common.scenarios.requests.http_requests
Namespace: default
Module: rally.plugins.common.scenarios.requests.http_requests
Boot a server from an image and then list all servers.
Measure the "nova list" command performance.
If you have only 1 user in your context, you will add 1 server on every iteration. So you will have more and more servers and will be able to measure the performance of the "nova list" command depending on the number of servers owned by users.
Namespace: default
Parameters:
image: image to be used to boot an instance
flavor: flavor to be used to boot an instance
detailed information about all of them
kwargs: Optional additional arguments for server creation
List all servers.
This simple scenario test the nova list command by listing all the servers.
Namespace: default
Parameters:
should be listed
Boot and delete a server.
Optional 'min_sleep' and 'max_sleep' parameters allow the scenario to simulate a pause between volume creation and deletion (of random duration from [min_sleep, max_sleep]).
Namespace: default
Parameters:
Boot multiple servers in a single request and delete them.
Deletion is done in parallel with one request per server, not with a single request for all servers.
Namespace: default
Parameters:
Boot a server from volume and then delete it.
The scenario first creates a volume and then a server. Optional 'min_sleep' and 'max_sleep' parameters allow the scenario to simulate a pause between volume creation and deletion (of random duration from [min_sleep, max_sleep]).
Namespace: default
Parameters:
image: image to be used to boot an instance
flavor: flavor to be used to boot an instance
volume_size: volume size (in GB)
multiple backends
min_sleep: Minimum sleep time in seconds (non-negative)
max_sleep: Maximum sleep time in seconds (non-negative)
force_delete: True if force_delete should be used
kwargs: Optional additional arguments for server creation
Boot a server and run specified actions against it.
Actions should be passed into the actions parameter. Available actions are 'hard_reboot', 'soft_reboot', 'stop_start', 'rescue_unrescue', 'pause_unpause', 'suspend_resume', 'lock_unlock' and 'shelve_unshelve'. Delete server after all actions were completed.
Namespace: default
Parameters:
image: image to be used to boot an instance
flavor: flavor to be used to boot an instance
force_delete: True if force_delete should be used
dictionary speicifes an action to be performed in the following format: {"action_name": <no_of_iterations>}
kwargs: Optional additional arguments for server creation
Boot a server, lock it, then unlock and delete it.
Optional 'min_sleep' and 'max_sleep' parameters allow the scenario to simulate a pause between locking and unlocking the server (of random duration from min_sleep to max_sleep).
Namespace: default
Parameters:
image: image to be used to boot an instance
flavor: flavor to be used to boot an instance
in seconds
in seconds
force_delete: True if force_delete should be used
kwargs: Optional additional arguments for server creation
Boot a server, make its snapshot and delete both.
Namespace: default
Parameters:
Boot a server.
Assumes that cleanup is done elsewhere.
Namespace: default
Parameters:
Boot a server from volume.
The scenario first creates a volume and then a server. Assumes that cleanup is done elsewhere.
Namespace: default
Parameters:
image: image to be used to boot an instance
flavor: flavor to be used to boot an instance
volume_size: volume size (in GB)
multiple backends
auto_assign_nic: True if NICs should be assigned
kwargs: Optional additional arguments for server creation
Boot a server, then resize and delete it.
This test will confirm the resize by default, or revert the resize if confirm is set to false.
Namespace: default
Parameters:
Create a VM from image, attach a volume to it and resize.
Simple test to create a VM and attach a volume, then resize the VM, detach the volume then delete volume and VM. Optional 'min_sleep' and 'max_sleep' parameters allow the scenario to simulate a pause between attaching a volume and running resize (of random duration from range [min_sleep, max_sleep]).
Namespace: default
Parameters:
image: Glance image name to use for the VM
flavor: VM flavor name
to_flavor: flavor to be used to resize the booted instance
volume_size: volume size (in GB)
min_sleep: Minimum sleep time in seconds (non-negative)
max_sleep: Maximum sleep time in seconds (non-negative)
force_delete: True if force_delete should be used
confirm: True if need to confirm resize else revert resize
else use rally cleanup to remove resources
boot_server_kwargs: optional arguments for VM creation
create_volume_kwargs: optional arguments for volume creation
Boot a server from volume, then resize and delete it.
The scenario first creates a volume and then a server. Optional 'min_sleep' and 'max_sleep' parameters allow the scenario to simulate a pause between volume creation and deletion (of random duration from [min_sleep, max_sleep]).
This test will confirm the resize by default, or revert the resize if confirm is set to false.
Namespace: default
Parameters:
image: image to be used to boot an instance
flavor: flavor to be used to boot an instance
to_flavor: flavor to be used to resize the booted instance
volume_size: volume size (in GB)
min_sleep: Minimum sleep time in seconds (non-negative)
max_sleep: Maximum sleep time in seconds (non-negative)
force_delete: True if force_delete should be used
confirm: True if need to confirm resize else revert resize
else use rally cleanup to remove resources
boot_server_kwargs: optional arguments for VM creation
create_volume_kwargs: optional arguments for volume creation
Create a server, suspend, resume and then delete it
Namespace: default
Parameters:
Create a server, pause, unpause and then delete it
Namespace: default
Parameters:
Create a server, shelve, unshelve and then delete it
Namespace: default
Parameters:
Live Migrate a server.
This scenario launches a VM on a compute node available in the availability zone and then migrates the VM to another compute node on the same availability zone.
Optional 'min_sleep' and 'max_sleep' parameters allow the scenario to simulate a pause between VM booting and running live migration (of random duration from range [min_sleep, max_sleep]).
Namespace: default
Parameters:
image: image to be used to boot an instance
flavor: flavor to be used to boot an instance
block_migration: Specifies the migration type
on migrated instance or not
min_sleep: Minimum sleep time in seconds (non-negative)
max_sleep: Maximum sleep time in seconds (non-negative)
kwargs: Optional additional arguments for server creation
Boot a server from volume and then migrate it.
The scenario first creates a volume and a server booted from the volume on a compute node available in the availability zone and then migrates the VM to another compute node on the same availability zone.
Optional 'min_sleep' and 'max_sleep' parameters allow the scenario to simulate a pause between VM booting and running live migration (of random duration from range [min_sleep, max_sleep]).
Namespace: default
Parameters:
image: image to be used to boot an instance
flavor: flavor to be used to boot an instance
volume_size: volume size (in GB)
multiple backends
block_migration: Specifies the migration type
on migrated instance or not
force_delete: True if force_delete should be used
min_sleep: Minimum sleep time in seconds (non-negative)
max_sleep: Maximum sleep time in seconds (non-negative)
kwargs: Optional additional arguments for server creation
Create a VM, attach a volume to it and live migrate.
Simple test to create a VM and attach a volume, then migrate the VM, detach the volume and delete volume/VM.
Optional 'min_sleep' and 'max_sleep' parameters allow the scenario to simulate a pause between attaching a volume and running live migration (of random duration from range [min_sleep, max_sleep]).
Namespace: default
Parameters:
image: Glance image name to use for the VM
flavor: VM flavor name
size: volume size (in GB)
block_migration: Specifies the migration type
on migrated instance or not
boot_server_kwargs: optional arguments for VM creation
create_volume_kwargs: optional arguments for volume creation
min_sleep: Minimum sleep time in seconds (non-negative)
max_sleep: Maximum sleep time in seconds (non-negative)
Migrate a server.
This scenario launches a VM on a compute node available in the availability zone, and then migrates the VM to another compute node on the same availability zone.
Namespace: default
Parameters:
Rebuild a server.
This scenario launches a VM, then rebuilds that VM with a different image.
Namespace: default
Parameters:
Boot a server and associate a floating IP to it.
Namespace: default
Parameters:
Show server details.
This simple scenario tests the nova show command by retrieving the server details.
Namespace: default
Parameters:
Returns: Server details
Get text console output from server.
This simple scenario tests the nova console-log command by retrieving the text console log output.
Namespace: default
Parameters:
image: image to be used to boot an instance
flavor: flavor to be used to boot an instance
None (default value) or -1 means unlimited length.
kwargs: Optional additional arguments for server creation
Returns: Text console log output for server
Boot a server, then update its name and description.
The scenario first creates a server, then update it. Assumes that cleanup is done elsewhere.
Namespace: default
Parameters:
Boot a server from a snapshot.
The scenario first creates a volume and creates a snapshot from this volume, then boots a server from the created snapshot. Assumes that cleanup is done elsewhere.
Namespace: default
Parameters:
image: image to be used to boot an instance
flavor: flavor to be used to boot an instance
volume_size: volume size (in GB)
multiple backends
auto_assign_nic: True if NICs should be assigned
kwargs: Optional additional arguments for server creation
Launch and delete a Sahara Cluster.
This scenario launches a Hadoop cluster, waits until it becomes 'Active' and deletes it.
Namespace: default
Parameters:
created node groups. Deprecated.
instance of the cluster
the cluster
workers_count: number of worker instances in a cluster
plugin_name: name of a provisioning plugin
the specified plugin.
IPs will be allocated. Sahara will determine automatically how to treat this depending on its own configurations. Defaults to None because in some cases Sahara may work w/o Floating IPs.
attached to every cluster node
volumes_size: size of each Cinder volume in GB
create a Security Group for each Node Group in the Cluster automatically.
while creating VMs. If auto_security_group is set to True, this list can be left empty.
Group
Cluster
one per compute node.
do not assign floating ips to workers.
automatically configured during cluster creation. If False, the configuration values should be specify manually
Launch, scale and delete a Sahara Cluster.
This scenario launches a Hadoop cluster, waits until it becomes 'Active'. Then a series of scale operations is applied. The scaling happens according to numbers listed in
Namespace: default
Parameters:
created node groups. Deprecated.
instance of the cluster
the cluster
workers_count: number of worker instances in a cluster
plugin_name: name of a provisioning plugin
the specified plugin.
remove worker nodes from the cluster
IPs will be allocated. Sahara will determine automatically how to treat this depending on its own configurations. Defaults to None because in some cases Sahara may work w/o Floating IPs.
for fixed IPs. This parameter is ignored when Nova Network is set up.
attached to every cluster node
volumes_size: size of each Cinder volume in GB
create a Security Group for each Node Group in the Cluster automatically.
while creating VMs. If auto_security_group is set to True this list can be left empty.
Group
Cluster
one per compute node.
do not assign floating ips to workers.
automatically configured during cluster creation. If False, the configuration values should be specify manually
Create and execute a Sahara EDP Job.
This scenario Creates a Job entity and launches an execution on a Cluster.
Namespace: default
Parameters:
job_type: type of the Data Processing Job
configs: config dict that will be passed to a Job Execution
used to create different atomic actions for each job in a sequence
Create and execute a sequence of the Sahara EDP Jobs.
This scenario Creates a Job entity and launches an execution on a Cluster for every job object provided.
Namespace: default
Parameters:
Create and execute Sahara EDP Jobs on a scaling Cluster.
This scenario Creates a Job entity and launches an execution on a Cluster for every job object provided. The Cluster is scaled according to the deltas values and the sequence is launched again.
Namespace: default
Parameters:
jobs: list of jobs that should be executed in one context
remove worker nodes from the cluster
Create and list Sahara Node Group Templates.
This scenario creates two Node Group Templates with different set of node processes. The master Node Group Template contains Hadoop's management processes. The worker Node Group Template contains Hadoop's worker processes.
By default the templates are created for the vanilla Hadoop provisioning plugin using the version 1.2.1
After the templates are created the list operation is called.
Namespace: default
Parameters:
created node groups
plugin_name: name of a provisioning plugin
the specified plugin.
automatically configured during cluster creation. If False, the configuration values should be specify manually
Module: rally.plugins.openstack.scenarios.sahara.node_group_templates
Create and delete Sahara Node Group Templates.
This scenario creates and deletes two most common types of Node Group Templates.
By default the templates are created for the vanilla Hadoop provisioning plugin using the version 1.2.1
Namespace: default
Parameters:
created node groups
plugin_name: name of a provisioning plugin
the specified plugin.
automatically configured during cluster creation. If False, the configuration values should be specify manually
Module: rally.plugins.openstack.scenarios.sahara.node_group_templates
Display results as stacked area.
This plugin processes additive data and displays it in HTML report as stacked area with X axis bound to iteration number. Complete output data is displayed as stacked area as well, without any processing.
Keys "description", "label" and "axis_label" are optional.
Examples of using this plugin in Scenario, for saving output data:
self.add_output(
additive={"title": "Additive data as stacked area",
"description": "Iterations trend for foo and bar",
"chart_plugin": "StackedArea",
"data": [["foo", 12], ["bar", 34]]},
complete={"title": "Complete data as stacked area",
"description": "Data is shown as stacked area, as-is",
"chart_plugin": "StackedArea",
"data": [["foo", [[0, 5], [1, 42], [2, 15], [3, 7]]],
["bar", [[0, 2], [1, 1.3], [2, 5], [3, 9]]]],
"label": "Y-axis label text",
"axis_label": "X-axis label text"})
Namespace: default
Module: rally.task.processing.charts
Display results as generic chart with lines.
This plugin processes additive data and displays it in HTML report as linear chart with X axis bound to iteration number. Complete output data is displayed as linear chart as well, without any processing.
Examples of using this plugin in Scenario, for saving output data:
self.add_output(
additive={"title": "Additive data as stacked area",
"description": "Iterations trend for foo and bar",
"chart_plugin": "Lines",
"data": [["foo", 12], ["bar", 34]]},
complete={"title": "Complete data as stacked area",
"description": "Data is shown as stacked area, as-is",
"chart_plugin": "Lines",
"data": [["foo", [[0, 5], [1, 42], [2, 15], [3, 7]]],
["bar", [[0, 2], [1, 1.3], [2, 5], [3, 9]]]],
"label": "Y-axis label text",
"axis_label": "X-axis label text"})
Namespace: default
Module: rally.task.processing.charts
Display results as pie, calculate average values for additive data.
This plugin processes additive data and calculate average values. Both additive and complete data are displayed in HTML report as pie chart.
Examples of using this plugin in Scenario, for saving output data:
self.add_output(
additive={"title": "Additive output",
"description": ("Pie with average data "
"from all iterations values"),
"chart_plugin": "Pie",
"data": [["foo", 12], ["bar", 34], ["spam", 56]]},
complete={"title": "Complete output",
"description": "Displayed as a pie, as-is",
"chart_plugin": "Pie",
"data": [["foo", 12], ["bar", 34], ["spam", 56]]})
Namespace: default
Module: rally.task.processing.charts
Display complete output as table, can not be used for additive data.
Use this plugin for complete output data to display it in HTML report as table. This plugin can not be used for additive data because it does not contain any processing logic.
Examples of using this plugin in Scenario, for saving output data:
self.add_output(
complete={"title": "Arbitrary Table",
"description": "Just show columns and rows as-is",
"chart_plugin": "Table",
"data": {"cols": ["foo", "bar", "spam"],
"rows": [["a row", 1, 2], ["b row", 3, 4],
["c row", 5, 6]]}})
Namespace: default
Module: rally.task.processing.charts
Calculate statistics for additive data and display it as table.
This plugin processes additive data and compose statistics that is displayed as table in HTML report.
Examples of using this plugin in Scenario, for saving output data:
self.add_output(
additive={"title": "Statistics",
"description": ("Table with statistics generated "
"from all iterations values"),
"chart_plugin": "StatsTable",
"data": [["foo stat", 12], ["bar", 34], ["spam", 56]]})
Namespace: default
Module: rally.task.processing.charts
Deploy Devstack cloud.
Sample configuration:
{
"type": "DevstackEngine",
"devstack_repo": "https://example.com/devstack/",
"local_conf": {
"ADMIN_PASSWORD": "secret"
},
"provider": {
"type": "ExistingServers",
"credentials": [{"user": "root", "host": "10.2.0.8"}]
}
}
Namespace: default
Just use an existing OpenStack deployment without deploying anything.
To use ExistingCloud, you should put credential information to the config:
{
"type": "ExistingCloud",
"auth_url": "http://localhost:5000/v2.0/",
"region_name": "RegionOne",
"endpoint_type": "public",
"admin": {
"username": "admin",
"password": "password",
"tenant_name": "demo"
},
"https_insecure": False,
"https_cacert": "",
}
Or, using keystone v3 API endpoint:
{
"type": "ExistingCloud",
"auth_url": "http://localhost:5000/v3/",
"region_name": "RegionOne",
"endpoint_type": "public",
"admin": {
"username": "admin",
"password": "admin",
"user_domain_name": "admin",
"project_name": "admin",
"project_domain_name": "admin",
},
"https_insecure": False,
"https_cacert": "",
}
To specify extra options use can use special "extra" parameter:
{
"type": "ExistingCloud",
"auth_url": "http://localhost:5000/v2.0/",
"region_name": "RegionOne",
"endpoint_type": "public",
"admin": {
"username": "admin",
"password": "password",
"tenant_name": "demo"
},
"https_insecure": False,
"https_cacert": "",
"extra": {"some_var": "some_value"}
}
Namespace: default
Deploy with other engines in lxc containers.
Sample configuration:
{
"type": "LxcEngine",
"provider": {
"type": "DummyProvider",
"credentials": [{"user": "root", "host": "example.net"}]
},
"distribution": "ubuntu",
"release": "raring",
"tunnel_to": ["10.10.10.10", "10.10.10.11"],
"start_lxc_network": "10.1.1.0/24",
"container_name_prefix": "devstack-node",
"containers_per_host": 16,
"start_script": "~/start.sh",
"engine": { ... }
}
Namespace: default
Module: rally.deployment.engines.lxc
Deploy multihost cloud with existing engines.
Sample configuration:
{
"type": "MultihostEngine",
"controller": {
"type": "DevstackEngine",
"provider": {
"type": "DummyProvider"
}
},
"nodes": [
{"type": "Engine1", "config": "Config1"},
{"type": "Engine2", "config": "Config2"},
{"type": "Engine3", "config": "Config3"},
]
}
If {controller_ip} is specified in configuration values, it will be replaced with controller address taken from credential returned by controller engine:
...
"nodes": [
{
"type": "DevstackEngine",
"local_conf": {
"GLANCE_HOSTPORT": "{controller_ip}:9292",
...
Namespace: default
Provide lxc container(s) on given host.
Sample configuration:
{
"type": "LxcProvider",
"distribution": "ubuntu",
"start_lxc_network": "10.1.1.0/24",
"containers_per_host": 32,
"tunnel_to": ["10.10.10.10"],
"forward_ssh": false,
"container_name_prefix": "rally-multinode-02",
"host_provider": {
"type": "ExistingServers",
"credentials": [{"user": "root", "host": "host.net"}]
}
}
Namespace: default
Creates servers via PXE boot from given cobbler selector.
Cobbler selector may contain a combination of fields to select a number of system. It's user responsibility to provide selector which selects something. Since cobbler stores servers password encrypted the user needs to specify it configuration. All servers selected must have the same password.
Sample configuration:
{
"type": "CobblerProvider",
"host": "172.29.74.8",
"user": "cobbler",
"password": "cobbler",
"system_password": "password"
"selector": {"profile": "cobbler_profile_name", "owners": "user1"}
}
Namespace: default
Just return endpoints from its own configuration.
Sample configuration:
{
"type": "ExistingServers",
"credentials": [{"user": "root", "host": "localhost"}]
}
Namespace: default
Provide VMs using an existing OpenStack cloud.
Sample configuration:
{
"type": "OpenStackProvider",
"amount": 42,
"user": "admin",
"tenant": "admin",
"password": "secret",
"auth_url": "http://example.com/",
"flavor_id": 2,
"image": {
"checksum": "75846dd06e9fcfd2b184aba7fa2b2a8d",
"url": "http://example.com/disk1.img",
"name": "Ubuntu Precise(added by rally)",
"format": "qcow2",
"userdata": "disable_root: false"
},
"secgroup_name": "Rally"
}
Namespace: default
Create VMs from prebuilt templates.
Sample configuration:
{
"type": "VirshProvider",
"connection": "alex@performance-01",
"template_name": "stack-01-devstack-template",
"template_user": "ubuntu",
"template_password": "password"
}
where :
Namespace: default