Merge "Add feature_request mechanism"

doc/README.rst

@@ -0,0 +1,37 @@
+========================
+Content of doc directory
+========================
+
+This directory contains everything that is related to documentation and
+bureaucracy. You can find here 4 subdirectories:
+
+
+feature_request
+~~~~~~~~~~~~~~~
+
+If some use case is not covered by Rally, it is the right place to request it.
+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
+~~~~~~
+
+Source of documentation. Latest version of documentation_.
+
+.. _documentation: http://rally.readthedocs.org/
+
+
+user_stories
+~~~~~~~~~~~~
+
+Place where you can share any of Rally user experience. E.g. fixing some bugs,
+measuring performance of different architectures or comparing different
+hardware and so on..

doc/feature_request/LDAP_support.rst

@@ -0,0 +1,23 @@
+===============================================
+Support benchmarking clouds that are using LDAP
+===============================================
+
+Use Case
+--------
+
+A lot of production clouds are using LDAP with read only access. It means
+that load can be generated only by existing in system users and there is no admin access.
+
+
+Problem Description
+-------------------
+
+Rally is using admin access to create temporary users that will be used to
+produce load.
+
+
+Possible Solution
+-----------------
+
+* Drop admin requirements
+* Add way to pass already existing users

doc/feature_request/README.rst

@@ -0,0 +1,11 @@
+================
+Feature requests
+================
+
+To request a new feature you should create a document similar to other feature
+requests. And contribute it to this directory using next instruction_.
+
+If you don't have time to contribute via gerrit,
+please contact Boris Pavlovic (boris@pavlovic.me)
+
+.. _instruction:  https://wiki.openstack.org/wiki/Rally/Develop#How_to_contribute

doc/feature_request/comparing_results_of_2_tasks.rst

@@ -0,0 +1,24 @@
+=======================================
+Ability to compare results between task
+=======================================
+
+
+Use case
+--------
+
+During the work on performance it's essential to be able to compare results of
+similar task before and after change in system.
+
+
+
+Problem description
+-------------------
+
+There is no command to compare two or more tasks and get tables and graphs.
+
+
+
+Possible solution
+-----------------
+
+* Add command that accepts 2 tasks UUID and prints graphs that compares result

doc/feature_request/distributed_load_generation.rst

@@ -0,0 +1,20 @@
+===========================
+Distributed load generation
+===========================
+
+Use Case
+--------
+
+Some OpenStack projects (Marconi, MagnetoDB) require a real huge load,
+like 10-100k request per second for benchmarking.
+
+To generate such huge load Rally have to create load from different
+servers.
+
+
+Problem Description
+-------------------
+
+* Rally can't generate load from different servers
+* Result processing can't handle big amount of data
+* There is no support for chunking results

doc/feature_request/historical_performance_data.rst

@@ -0,0 +1,26 @@
+===========================
+Historical performance data
+===========================
+
+
+Use case
+--------
+
+OpenStack is really rapidly developed. Hundreds patches are merged daily
+and it's really hard to track how performance is changed during time.
+It will be nice to have a way to track performance of major functionality
+of OpenStack running periodically rally task and building graphs that represent
+how performance of specific method is changed during the time.
+
+
+Problem description
+-------------------
+
+There is no way to bind tasks
+
+
+Possible solution
+-----------------
+
+* Add grouping for tasks
+* Add command that creates historical graphs

doc/feature_request/multi_scenarios_load_gen.rst

@@ -0,0 +1,35 @@
+======================================
+Using multi scenarios to generate load
+======================================
+
+
+Use Case
+--------
+
+Rally should be able to generate real life load. Simultaneously create load
+on different components of OpenStack, e.g. simultaneously booting VM, uploading
+image and listing users.
+
+
+Problem Description
+-------------------
+
+At the moment Rally is able to run only 1 scenario per benchmark.
+Scenario are quite specific (e.g. boot and delete VM for example) and can't
+actually generate real life load.
+
+Writing a lot of specific benchmark scenarios that will produce more real life
+load will produce mess and a lot of duplication of code.
+
+
+Possible solution
+-----------------
+
+* Extend Rally task benchmark configuration in such way to support passing
+  multiple benchmark scenarios in singe benchmark context
+
+* Extend Rally task output format to support results of multiple scenarios in
+  single benchmark separately.
+
+* Extend rally task plot2html and rally task detailed to show results
+  separately for every scenario.

doc/feature_request/persistence_benchmark_env.rst

@@ -0,0 +1,30 @@
+================================================
+Add support of persistence benchmark environment
+================================================
+
+Use Case
+--------
+
+To benchmark many of operations like show, list, detailed you need to have
+already these resource in cloud. So it will be nice to be able to create
+benchmark environment once before benchmarking. The run some amount of
+benchmarks that are using it and at the end just delete all created resources
+by benchmark environment.
+
+
+Problem Description
+-------------------
+
+Fortunately Rally has already a mechanism for creating benchmark environment,
+that is used to create load. Unfortunately it's atomic operation:
+(create environment, make load, delete environment).
+This should be split to 3 separated steps.
+
+
+Possible solution
+-----------------
+
+* Add new CLI operations to work with benchmark environment:
+  (show, create, delete, list)
+
+* Allow task to start against benchmark environment (instead of deployment)

doc/feature_request/production_ready_cleanup.rst

@@ -0,0 +1,28 @@
+========================
+Production read cleanups
+========================
+
+Use Case
+--------
+
+Rally should delete in any case all resources that it created during benchmark.
+
+
+Problem Description
+-------------------
+
+* Deletion rate limit
+
+  You can kill cloud by deleting too many objects simultaneously, so deletion
+  rate limit is required
+
+* Retry on failures
+
+  There should be few attempts to delete resource in case of failures
+
+* Disaster recovery
+
+  Rally should use special name patterns, to be able to delete resources
+  in such case if something went wrong with server that is running rally. And
+  you have just new instance (without old rally db) of rally on new server.
+

doc/samples/README.rst

@@ -0,0 +1,14 @@
+============================
+Content of samples directory
+============================
+
+deployments
+~~~~~~~~~~~
+
+Input configurations for "rally deployment" command
+
+
+tasks
+~~~~~
+
+Input configurations for "rally task" command