Release 0.0.2

* Add new section in docs for release_notes

* Write release notes for 0.0.1 and 0.0.2 versions

* Move doc/feature_request/stop_scenario_after_several_errors to implemented

* Various improvements and fixes in docs

Change-Id: I787e320db5f7a17044a76f345612cd29d515f3ca
This commit is contained in:
Boris Pavlovic 2015-03-12 15:02:43 +03:00
parent c2a6ed3edd
commit cde656bae2
8 changed files with 161 additions and 22 deletions

View File

@ -14,13 +14,6 @@ To request new feature you should just explain use case on high level.
Technical details and writing code are not required at all.
samples
~~~~~~~
If you are looking for samples of deployments and benchmarks configuration
you are on the right way
source
~~~~~~

View File

@ -0,0 +1,58 @@
==================================
Stop scenario after several errors
==================================
Use case
--------
Starting long tests on the big environments.
Problem description
-------------------
When we start a rally scenarios on the env where keystone die we get a lot of
time from timeout
Example
-------
Times in hard tests
05:25:40 rally-scenarios.cinder
05:25:40 create-and-delete-volume [4074 iterations, 15 threads] OK 8.91
08:00:02 create-and-delete-snapshot [5238 iterations, 15 threads] OK 17.46
08:53:20 create-and-list-volume [4074 iterations, 15 threads] OK 3.18
12:04:14 create-snapshot-and-attach-volume [2619 iterations, 15 threads] FAIL
14:18:44 create-and-attach-volume [2619 iterations, 15 threads] FAIL
14:23:47 rally-scenarios.vm
14:23:47 boot_runcommand_metadata_delete [5 iterations, 5 threads] FAIL
16:30:46 rally-scenarios.nova
16:30:46 boot_and_list_server [5820 iterations, 15 threads] FAIL
19:19:30 resize_server [5820 iterations, 15 threads] FAIL
02:51:13 boot_and_delete_server_with_secgroups [5820 iterations, 60 threads] FAIL
Times in light variant
00:38:25 rally-scenarios.cinder
00:38:25 create-and-delete-volume [14 iterations, 1 threads] OK 5.30
00:40:39 create-and-delete-snapshot [18 iterations, 1 threads] OK 5.65
00:41:52 create-and-list-volume [14 iterations, 1 threads] OK 2.89
00:45:18 create-snapshot-and-attach-volume [9 iterations, 1 threads] OK 17.75
00:48:54 create-and-attach-volume [9 iterations, 1 threads] OK 20.04
00:52:29 rally-scenarios.vm
00:52:29 boot_runcommand_metadata_delete [5 iterations, 5 threads] OK 128.86
00:56:42 rally-scenarios.nova
00:56:42 boot_and_list_server [20 iterations, 1 threads] OK 6.98
01:04:48 resize_server [20 iterations, 1 threads] OK 22.90
In the hard test we have a lot of timeouts from keystone and a lot of time on
test execution
Possible solution
-----------------
Improve SLA check functionality to work "online". And add ability to control
execution process and stop load generation in case of sla check failures.

View File

@ -0,0 +1,12 @@
.. _release_notes/archive:
=================
All release notes
=================
.. toctree::
:glob:
:maxdepth: 1
archive/*
*

View File

@ -0,0 +1,28 @@
============
Rally v0.0.1
============
Information
-----------
+------------------+-----------------+
| Commits | **1039** |
+------------------+-----------------+
| Bug fixes | **0** |
+------------------+-----------------+
| Dev cycle | **547 days** |
+------------------+-----------------+
| Release date | **26/Jan/2015** |
+------------------+-----------------+
Details
-------
Rally is awesome tool for testing verifying and benchmarking OpenStack clouds.
A lot of people started using Rally in their CI/CD so Rally team should provide
more stable product with clear strategy of deprecation and upgrades.

View File

@ -36,3 +36,4 @@ Contents
gates
feature_requests
project_info
release_notes

View File

@ -8,7 +8,13 @@ deployments
Input configurations for "rally deployment" command
plugins
~~~~~~~
Samples of Rally plugins.
tasks
~~~~~
Input configurations for "rally task" command
Input configurations for "rally task" command

View File

@ -4,26 +4,67 @@ Tasks Configuration Samples
To specify your tasks, use configuration files in json or yaml format.
General structure of configuration file:
JSON schema of input task format:
::
{
"ScenarioClass.scenario_method":
"args": {
...
},
"runner": {
...
},
"context": {
...
}
"sla": {
...
"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

View File

@ -1,6 +1,6 @@
[metadata]
name = rally
version = 0.0.1
version = 0.0.2
summary = Benchmark System for OpenStack
description-file =
README.rst