[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:
parent
6761385d37
commit
b5142f1a01
@ -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.
|
@ -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
|
||||
|
||||
|
@ -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>`.
|
||||
|
@ -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
|
158
doc/source/tutorial/step_3_benchmarking_with_existing_users.rst
Normal file
158
doc/source/tutorial/step_3_benchmarking_with_existing_users.rst
Normal 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 won’t 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/)
|
@ -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.
|
@ -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
|
||||
---------------------
|
||||
|
@ -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 it’s important to reach the OpenStack cloud’s limits, from the other side the cloud shouldn’t 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 didn’t know how to stop the load until it was too late.
|
@ -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.
|
@ -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
|
||||
---------------------------------
|
||||
|
@ -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 |
|
||||
+---------------------------+----------------------------+--------------+------------------+
|
Loading…
Reference in New Issue
Block a user