From fc00bb4381ce491efae487c313aa1d3fdcd79d69 Mon Sep 17 00:00:00 2001 From: Ilya Shakhat Date: Thu, 14 May 2015 23:22:20 +0300 Subject: [PATCH] Minor docs improvements Change-Id: I4b6764d8730740df2e223b04a6ed97aafa4a1fc3 --- doc/source/architecture.rst | 30 +++++++++++++++++++----------- doc/source/examples.rst | 2 +- doc/source/usage.rst | 1 + 3 files changed, 21 insertions(+), 12 deletions(-) diff --git a/doc/source/architecture.rst b/doc/source/architecture.rst index fcc5159..6578908 100644 --- a/doc/source/architecture.rst +++ b/doc/source/architecture.rst @@ -21,7 +21,8 @@ Scenario execution involves the following steps: shaker --server-endpoint --scenario --report where: - * host:port - address of the machine where Shaker is installed and port is some arbitrary free port to bind the server to; + * host:port - address of the machine where Shaker is installed and + port is some arbitrary free port to bind the server to; * scenario - file name of the scenario (yaml file); * report - file name where report will be saved. @@ -31,20 +32,27 @@ Scenario execution involves the following steps: 4. The topology is deployed with help of Heat. The list of agents is extended with IP addresses and instance names. - 5. Shaker waits for all agents to connect. Once all agents are alive it means that the Quorum is full and everyone ready to execute the tests. + 5. Shaker waits for all agents to join. Once all agents are alive it means + that the quorum exists and everyone ready to execute the tests. - 6. Shaker starts tests one by one in order they listed in the scenario. The test definition is converted into the actual command that will be - executed by agent. Shaker schedules the command to be started at the same time on all agents. For networking testing only agents in ``master`` role - are involved. Slave agents are used as back-end for corresponding commands (i.e. they run iperf in server mode). + 6. Shaker starts tests one by one in order they are listed in the scenario. + Test definition is converted into the actual command that will be + executed by agent. Shaker schedules the command to be started at the same + time on all agents. For networking testing only agents in ``master`` role + are involved. Slave agents are used as back-end for corresponding commands + (i.e. they run iperf in server mode). - 7. Agents send their results to the server. Once all replies are received the test execution meant to be finished. If some agent didn't make it in + 7. Agents send their results to the server. Once all replies are received + the test execution meant to be finished. If some agent didn't make it in dedicated time it is marked as lost. - 8. Once all tests are executed Shaker can output the raw result in JSON format (option ``--output``). + 8. Once all tests are executed Shaker can output the raw result in JSON format + (if option ``--output`` is set). - 9. Shaker clears the topology with help of Heat. + 9. Shaker clears the topology by calling Heat. - 10. Shaker calculates statistics and aggregated charts. If there are any SLA statements they are also evaluated, the result can be stored in subunit format - (option ``--subunit``). + 10. Shaker calculates statistics and aggregated charts. If there are any + SLA statements they are also evaluated, the result can be stored in subunit format + (if option ``--subunit`` is set). - 11. Shaker generates report in HTML format. + 11. Shaker generates report in HTML format into file specified by ``--report`` option. diff --git a/doc/source/examples.rst b/doc/source/examples.rst index aa0dc3d..b60b229 100644 --- a/doc/source/examples.rst +++ b/doc/source/examples.rst @@ -49,7 +49,7 @@ L3 North-South -------------- This scenario tests the bandwidth between pairs of instances deployed in different virtual networks. Instances -with master agents are located in one network, instances with slave agents are reached via floating IP. +with master agents are located in one network, instances with slave agents are reached via their floating IPs. Each instance is deployed on its own compute node. The test increases the load from 1 pair pair until all available instances are used. diff --git a/doc/source/usage.rst b/doc/source/usage.rst index 730f6f4..e07f764 100644 --- a/doc/source/usage.rst +++ b/doc/source/usage.rst @@ -68,6 +68,7 @@ The execution part of scenario contains a list of tests that are executed one by simultaneously on all available agents. The level of concurrency can be controlled by option ``size``. There are 3 values available: + * ``size`` is not specified - all agents are involved; * ``size: linear_progression`` - the execution starts with 1 agent and increases by 1 until all agents are involved; * ``size: quadratic_progression`` - the execution starts with 1 agent (or 1 pair) and doubles until all agents are involved.