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. 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 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 gates
feature_requests feature_requests
project_info project_info
release_notes

View File

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

View File

@ -4,11 +4,50 @@ Tasks Configuration Samples
To specify your tasks, use configuration files in json or yaml format. To specify your tasks, use configuration files in json or yaml format.
General structure of configuration file: 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": [
{ {
"ScenarioClass.scenario_method":
"args": { "args": {
... ...
}, },
@ -17,13 +56,15 @@ General structure of configuration file:
}, },
"context": { "context": {
... ...
} },
"sla": { "sla": {
... ...
} }
} }
]
} }
ScanarioClass should be a subclass of the base Scenario class ScanarioClass should be a subclass of the base Scenario class
and scenario_method specifies what benchmark task should be run. Section and scenario_method specifies what benchmark task should be run. Section
"args" is also related to scenario. To learn more about scenarios "args" is also related to scenario. To learn more about scenarios

View File

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