Jump to: navigation, search

Difference between revisions of "Rally/RoadMap"

(More scenarios)
(Benchmarking Engine)
Line 29: Line 29:
 
# Purge resources of each user
 
# Purge resources of each user
 
# Destroy all users & tenants
 
# Destroy all users & tenants
 +
 +
 +
== Run multiple scenarios simultaneously ==
 +
 +
Okay we now how to make load on Nova: Boot & Destroy VM scenario
 +
But how will influence huge load of another Scenario: Create & Destroy Block device on Nova Scenario?
 +
 +
This could be also easily extended. For example we will get special name for such benchmarks:
 +
<pre>
 +
benchmark: {
 +
  "@composed" : {
 +
      "NovaServers.boot_and_destroy": [...],
 +
      ....
 +
  },
 +
  ""
 +
}
 +
</pre>
 +
  
  

Revision as of 01:27, 16 October 2013

Benchmarking Engine

Add support of Users & Tenants out of box

At this moment we are supporting next 3 parameters:

  1. timeout - this is the timeout of 1 scenario loop
  2. times - how much loops of scenario to run
  3. concurrent - how much loops should be run simultaneously

All tests are run from one user => it is not real situations.

We are going to add two new parameters:

  1. tenants - how much tenants to create
  2. users_pro_tenant - how much users should be in each tenant


Benchmark Engine will create all tenants & users, and prepare OpenStack python clients, before starting benchmarking.


Add generic cleanup mechanism

In benchmarks we are creating a lot of different resources: Tenants, Users, VMs, Snapshots, Block devices.

If something went wrong, or test is not well written we will get a lot of allocated resources that could make influence on next benchmarks. So we should clean up our OpenStack.

Such generic cleanup could be easily implemented. As we are creating all resources, using tenants, created before running benchmark Scenario.

We need to make only 2 steps:

  1. Purge resources of each user
  2. Destroy all users & tenants


Run multiple scenarios simultaneously

Okay we now how to make load on Nova: Boot & Destroy VM scenario But how will influence huge load of another Scenario: Create & Destroy Block device on Nova Scenario?

This could be also easily extended. For example we will get special name for such benchmarks:

benchmark: {
  "@composed" : {
      "NovaServers.boot_and_destroy": [...], 
      ....
  },
  ""
}


More scenarios

We should make more different benchmark scenarios:

  1. E.g Restarting VMs
  2. Associating Floating IPs
  3. Creating & Destroying Block Devices, Snapshots and so on
  4. .....
  5. PROFIT!!

Data processing

Profiling

Make it work out of box

Fix or get rid of Zipkin

Deploying