[Docs] Existing users and other fixes

* Add a tutorial step about the new existing users feature (step 3)
* Move the corresponding feature request to 'implemented' and modify it a bit
* Rename step 2 to "Rally input task format"
* Add tables of contents to the lessons
* Other fixes that make docs more precise

Change-Id: Ic800fdfa3df883f267ddcae2165f804c11699bd0
This commit is contained in:
Mikhail Dubov 2015-04-28 16:45:26 +03:00
parent 6761385d37
commit b5142f1a01
11 changed files with 209 additions and 28 deletions

View File

@ -19,5 +19,12 @@ produce load.
Possible Solution
-----------------
* Drop admin requirements
* Add way to pass already existing users
* Add some way to pass already existing users
Current Solution
----------------
* Allow the user to specify existing users in the configuration of the *ExistingCloud* deployment plugin
* When such an *ExistingCloud* deployment is active, and the benchmark task file does not specify the *"users"* context, use the existing users instead of creating the temporary ones.
* Modify the *rally show ...* commands to list resources for each user separately.

View File

@ -147,7 +147,7 @@ Documentation
* New tutorial **task templates**
https://rally.readthedocs.org/en/latest/tutorial/step_4_task_templates.html
https://rally.readthedocs.org/en/latest/tutorial/step_5_task_templates.html
* Various fixes

View File

@ -18,6 +18,9 @@
Step 1. Setting up the environment and running a benchmark from samples
=======================================================================
.. contents::
:local:
In this demo, we will show how to perform some basic operations in Rally, such as registering an OpenStack cloud, benchmarking it and generating benchmark reports.
We assume that you have a :ref:`Rally installation <tutorial_step_0_installation>` and an already existing OpenStack deployment with Keystone available at *<KEYSTONE_AUTH_URL>*.
@ -208,12 +211,12 @@ One of the most beautiful things in Rally is its task report generation mechanis
$ rally task report --out=report1.html --open
This will produce an HTML page with the overview of all the scenarios that you've included into the last benchmark task completed in Rally (in our case, this is just one scenario, and we will cover the topic of multiple scenarios in one task in :ref:`the next step of our tutorial <tutorial_step_2_running_multple_benchmarks_in_a_single_task>`):
This will produce an HTML page with the overview of all the scenarios that you've included into the last benchmark task completed in Rally (in our case, this is just one scenario, and we will cover the topic of multiple scenarios in one task in :ref:`the next step of our tutorial <tutorial_step_2_input_task_format>`):
.. image:: ../images/Report-Overview.png
:align: center
This aggregating table shows the duration of the load produced by the corresponding scenario (*"Load duration"*), the overall benchmark scenario execution time, including the duration of environment preparation with contexts (*"Full duration"*), the number of iterations of each scenario (*"Iterations"*), the type of the load used while running the scenario (*"Runner"*), the number of failed iterations (*"Errors"*) and finally whether the scenario has passed certain Success Criteria (*"SLA"*) that were set up by the user in the input configuration file (we will cover these criteria in :ref:`one of the next steps <tutorial_step_3_adding_success_criteria_for_benchmarks>`).
This aggregating table shows the duration of the load produced by the corresponding scenario (*"Load duration"*), the overall benchmark scenario execution time, including the duration of environment preparation with contexts (*"Full duration"*), the number of iterations of each scenario (*"Iterations"*), the type of the load used while running the scenario (*"Runner"*), the number of failed iterations (*"Errors"*) and finally whether the scenario has passed certain Success Criteria (*"SLA"*) that were set up by the user in the input configuration file (we will cover these criteria in :ref:`one of the next steps <tutorial_step_4_adding_success_criteria_for_benchmarks>`).
By navigating in the left panel, you can switch to the detailed view of the benchmark results for the only scenario we included into our task, namely **NovaServers.boot_and_delete_server**:
@ -228,4 +231,4 @@ This page, along with the description of the success criteria used to check the
Note that all the charts on the report pages are very dynamic: you can change their contents by clicking the switches above the graph and see more information about its single points by hovering the cursor over these points.
Take some time to play around with these graphs
and then move on to :ref:`the next step of our tutorial <tutorial_step_2_running_multple_benchmarks_in_a_single_task>`.
and then move on to :ref:`the next step of our tutorial <tutorial_step_2_input_task_format>`.

View File

@ -13,15 +13,18 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_2_running_multple_benchmarks_in_a_single_task:
.. _tutorial_step_2_input_task_format:
Step 2. Running multiple benchmarks in a single task
====================================================
Step 2. Rally input task format
===============================
Rally input task syntax
.. contents::
:local:
Basic input task syntax
-----------------------
Rally comes with a really great collection of :ref:`benchmark scenarios <tutorial_step_7_discovering_more_benchmark_scenarios>` and in most real-world scenarios you will use multiple scenarios to test your OpenStack cloud. Rally makes it very easy to run **different benchmarks defined in a single benchmark task**. To do so, use the following syntax:
Rally comes with a really great collection of :ref:`benchmark scenarios <tutorial_step_8_discovering_more_benchmark_scenarios>` and in most real-world scenarios you will use multiple scenarios to test your OpenStack cloud. Rally makes it very easy to run **different benchmarks defined in a single benchmark task**. To do so, use the following syntax:
.. code-block:: none
@ -35,9 +38,10 @@ where *<benchmark_config>*, as before, is a dictionary:
.. code-block:: none
{
"args": { scenario-specific arguments },
"runner": {"type": ..., }
...
"args": { <scenario-specific arguments> },
"runner": { <type of the runner and its specific parameters> },
"context": { <contexts needed for this scenario> },
"sla": { <different SLA configs> }
}
Multiple benchmarks in a single task

View File

@ -0,0 +1,158 @@
..
Copyright 2015 Mirantis Inc. All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_3_benchmarking_with_existing_users:
Step 3. Benchmarking OpenStack with existing users
==================================================
.. contents::
:local:
Motivation
----------
There are two very important reasons from the production world of why it is preferable to use some already existing users to benchmark your OpenStack cloud:
1. *Read-only Keystone Backends:* creating temporary users for benchmark scenarios in Rally is just impossible in case of r/o Keystone backends like *LDAP* and *AD*.
2. *Safety:* Rally can be run from an isolated group of users, and if something goes wrong, this wont affect the rest of the cloud users.
Registering existing users in Rally
-----------------------------------
The information about existing users in your OpenStack cloud should be passed to Rally at the :ref:`deployment initialization step <tutorial_step_1_setting_up_env_and_running_benchmark_from_samples>`. You have to use the **ExistingCloud** deployment plugin that just provides Rally with credentials of an already existing cloud. The difference from the deployment configuration we've seen previously is that you should set up the *"users"* section with the credentials of already existing users. Let's call this deployment configuration file *existing_users.json*:
.. code-block:: none
{
"type": "ExistingCloud",
"auth_url": "http://example.net:5000/v2.0/",
"region_name": "RegionOne",
"endpoint_type": "public",
"admin": {
"username": "admin",
"password": "pa55word",
"tenant_name": "demo"
},
"users": [
{
"username": "b1",
"password": "1234",
"tenant_name": "testing"
},
{
"username": "b2",
"password": "1234",
"tenant_name": "testing"
}
]
}
This deployment configuration requires some basic information about the OpenStack cloud like the region name, auth url. admin user credentials, and any amount of users already existing in the system. Rally will use their credentials to generate load in against this deployment as soon as we register it as usual:
.. code-block:: none
$ rally deployment create --file existings_users --name our_cloud
+--------------------------------------+----------------------------+-----------+------------------+--------+
| uuid | created_at | name | status | active |
+--------------------------------------+----------------------------+-----------+------------------+--------+
| 1849a9bf-4b18-4fd5-89f0-ddcc56eae4c9 | 2015-03-28 02:43:27.759702 | our_cloud | deploy->finished | |
+--------------------------------------+----------------------------+-----------+------------------+--------+
Using deployment: 1849a9bf-4b18-4fd5-89f0-ddcc56eae4c9
~/.rally/openrc was updated
After that, the **rally show** command lists the resources for each user separately:
.. code-block:: none
$ rally show images
Images for user `admin` in tenant `admin`:
+--------------------------------------+---------------------------------+-----------+
| UUID | Name | Size (B) |
+--------------------------------------+---------------------------------+-----------+
| 041cfd70-0e90-4ed6-8c0c-ad9c12a94191 | cirros-0.3.2-x86_64-uec | 25165824 |
| 87710f09-3625-4496-9d18-e20e34906b72 | Fedora-x86_64-20-20140618-sda | 209649664 |
| b0f269be-4859-48e0-a0ca-03fb80d14602 | cirros-0.3.2-x86_64-uec-ramdisk | 3723817 |
| d82eaf7a-ff63-4826-9aa7-5fa105610e01 | cirros-0.3.2-x86_64-uec-kernel | 4969360 |
+--------------------------------------+---------------------------------+-----------+
Images for user `b1` in tenant `testing`:
+--------------------------------------+---------------------------------+-----------+
| UUID | Name | Size (B) |
+--------------------------------------+---------------------------------+-----------+
| 041cfd70-0e90-4ed6-8c0c-ad9c12a94191 | cirros-0.3.2-x86_64-uec | 25165824 |
| 87710f09-3625-4496-9d18-e20e34906b72 | Fedora-x86_64-20-20140618-sda | 209649664 |
| b0f269be-4859-48e0-a0ca-03fb80d14602 | cirros-0.3.2-x86_64-uec-ramdisk | 3723817 |
| d82eaf7a-ff63-4826-9aa7-5fa105610e01 | cirros-0.3.2-x86_64-uec-kernel | 4969360 |
+--------------------------------------+---------------------------------+-----------+
Images for user `b2` in tenant `testing`:
+--------------------------------------+---------------------------------+-----------+
| UUID | Name | Size (B) |
+--------------------------------------+---------------------------------+-----------+
| 041cfd70-0e90-4ed6-8c0c-ad9c12a94191 | cirros-0.3.2-x86_64-uec | 25165824 |
| 87710f09-3625-4496-9d18-e20e34906b72 | Fedora-x86_64-20-20140618-sda | 209649664 |
| b0f269be-4859-48e0-a0ca-03fb80d14602 | cirros-0.3.2-x86_64-uec-ramdisk | 3723817 |
| d82eaf7a-ff63-4826-9aa7-5fa105610e01 | cirros-0.3.2-x86_64-uec-kernel | 4969360 |
+--------------------------------------+---------------------------------+-----------+
With this new deployment being active, Rally will use the already existing users *"b1"* and *"b2"* instead of creating the temporary ones when launching benchmark task that do not specify the *"users"* context.
Running benchmark scenarios with existing users
-----------------------------------------------
After you have registered a deployment with existing users, don't forget to remove the *"users"* context from your benchmark task configuration if you want to use existing users, like in the following configuration file (*boot-and-delete.json*):
.. code-block:: none
{
"NovaServers.boot_and_delete_server": [
{
"args": {
"flavor": {
"name": "m1.nano"
},
"image": {
"name": "^cirros.*uec$"
},
"force_delete": false
},
"runner": {
"type": "constant",
"times": 10,
"concurrency": 2
},
"context": {}
}
]
}
When you start this task, it will use the existing users *"b1"* and *"b2"* instead of creating the temporary ones:
.. code-block:: none
$ rally task start samples/tasks/scenarios/nova/boot-and-delete.json
...
It goes without saying that support of benchmarking with predefined users simplifies the usage of Rally for generating loads against production clouds.
(based on: http://boris-42.me/rally-can-generate-load-with-passed-users-now/)

View File

@ -13,11 +13,14 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_3_adding_success_criteria_for_benchmarks:
.. _tutorial_step_4_adding_success_criteria_for_benchmarks:
Step 3. Adding success criteria (SLA) for benchmarks
Step 4. Adding success criteria (SLA) for benchmarks
====================================================
.. contents::
:local:
SLA - Service-Level Agreement (Success Criteria)
------------------------------------------------
@ -141,4 +144,4 @@ Somewhat more detailed information about SLA is displayed on the scenario pages:
.. image:: ../images/Report-SLA-Scenario.png
:align: center
Success criteria present a very useful concept that enables not only to analyze the outcome of your benchmark tasks, but also to control their execution. In :ref:`one of the next sections <tutorial_step_5_aborting_load_generation_on_sla_failure>` of our tutorial, we will show how to use SLA to abort the load generation before your OpenStack goes wrong.
Success criteria present a very useful concept that enables not only to analyze the outcome of your benchmark tasks, but also to control their execution. In :ref:`one of the next sections <tutorial_step_6_aborting_load_generation_on_sla_failure>` of our tutorial, we will show how to use SLA to abort the load generation before your OpenStack goes wrong.

View File

@ -13,11 +13,14 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_4_task_templates:
.. _tutorial_step_5_task_templates:
Step 4. Rally task templates
Step 5. Rally task templates
============================
.. contents::
:local:
Basic template syntax
---------------------

View File

@ -13,9 +13,9 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_5_aborting_load_generation_on_sla_failure:
.. _tutorial_step_6_aborting_load_generation_on_sla_failure:
Step 5. Aborting load generation on success criteria failure
Step 6. Aborting load generation on success criteria failure
============================================================
Benchmarking pre-production and production OpenStack clouds is not a trivial task. From the one side its important to reach the OpenStack clouds limits, from the other side the cloud shouldnt be damaged. Rally aims to make this task as simple as possible. Since the very beginning Rally was able to generate enough load for any OpenStack cloud. Generating too big a load was the major issue for production clouds, because Rally didnt know how to stop the load until it was too late.

View File

@ -13,9 +13,9 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_6_working_with_multple_openstack_clouds:
.. _tutorial_step_7_working_with_multple_openstack_clouds:
Step 6. Working with multiple OpenStack clouds
Step 7. Working with multiple OpenStack clouds
==============================================
Rally is an awesome tool that allows you to work with multiple clouds and can itself deploy them. We already know how to work with :ref:`a single cloud <tutorial_step_1_setting_up_env_and_running_benchmark_from_samples>`. Let us now register 2 clouds in Rally: the one that we have access to and the other that we know is registered with wrong credentials.

View File

@ -13,11 +13,14 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_7_discovering_more_benchmark_scenarios:
.. _tutorial_step_8_discovering_more_benchmark_scenarios:
Step 7. Discovering more benchmark scenarios in Rally
Step 8. Discovering more benchmark scenarios in Rally
=====================================================
.. contents::
:local:
Scenarios in the Rally repository
---------------------------------

View File

@ -13,9 +13,9 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_8_working_with_multple_openstack_clouds:
.. _tutorial_step_9_deploying_openstack:
Step 8. Deploying OpenStack from Rally
Step 9. Deploying OpenStack from Rally
======================================
Along with supporting already existing OpenStack deployments, Rally itself can **deploy OpenStack automatically** by using one of its *deployment engines*. Take a look at other `deployment configuration file samples <https://github.com/openstack/rally/tree/master/samples/deployments>`_. For example, *devstack-in-existing-servers.json* is a deployment configuration file that tells Rally to deploy OpenStack with **Devstack** on the existing servers with given credentials:
@ -34,7 +34,7 @@ You can try to deploy OpenStack in your Virtual Machine using this script. Edit
.. code-block:: none
$ rally deployment create --file=samples/deployments/devstack-in-existing-servers.json --name=new-devstack
$ rally deployment create --file=samples/deployments/for_deploying_openstack_with_rally/devstack-in-existing-servers.json --name=new-devstack
+---------------------------+----------------------------+--------------+------------------+
| uuid | created_at | name | status |
+---------------------------+----------------------------+--------------+------------------+