openstack/rally
Code Issues Proposed changes

Merge "[Docs] Various fixes"

Browse Source
This commit is contained in:
Jenkins 2015-04-21 16:57:18 +00:00 committed by Gerrit Code Review
commit 5ec83a73bd
17 changed files with 24 additions and 580 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/release_notes/archive/v0.0.2.rst
View File

@ -118,13 +118,13 @@ Plugins
[fix] CinderVolumes.create_and_attach_volume
Pass optional **kwargs only to create server command
Pass optional \*\*kwargs only to create server command
[fix] GlanceImages.create_image_and_boot_instances
Pass optional **kwargs only to create server command
Pass optional \*\*kwargs only to create server command
[fix] TempestScenario.* removed stress cleanup.
[fix] TempestScenario.\* removed stress cleanup.
Major issue is that tempest stress cleanup cleans whole OpenStack.
This is very dangerous, so it's better to remove it and leave some
@ -132,7 +132,7 @@ Plugins
[improved] NovaSecGroup.boot_and_delete_server_with_secgroups
Add optional **kwargs that are passed to boot server comment
Add optional \*\*kwargs that are passed to boot server comment
* **Benchmark Context**:

2
doc/release_notes/v0.0.3.rst
View File

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

2
doc/source/contribute.rst
View File

@ -72,7 +72,7 @@ Several Linux distributions (notably Fedora 16 and Ubuntu 12.04) are also starti
tox
**(NOTE: you should have installed tox<=1.6.1 )**
**(NOTE: you should have installed tox<=1.6.1)**
If you extend Rally with new functionality, make sure you have also provided unit and/or functional tests for it.

127
doc/source/deploy_engines.rst
View File

@ -1,127 +0,0 @@
..
Copyright 2014 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.
.. _deploy_engines:
Deploy engines
==============
Introduction
------------
One of the core entities in Rally architecture are the Deploy engines. The task of a deploy engine is to control the process of deploying some OpenStack distribution like DevStack or FUEL before any benchmarking procedures take place. Every deploy engine should implement the following fairly simple interface:
..
**constuctor**, which takes a deployment entity as its only parameter;
..
**deploy()**, which should deploy the appropriate OpenStack distribution given the cloud config from the deployment object the engine was initialized with (possibly using one of available :ref:`server providers <server_providers>`). The method should also return a dictionary with endpoints of the deployed OpenStack distribution;
..
**cleanup()**, which should clean up the OpenStack deployment (again, possibly using one of available :ref:`server providers <server_providers>`).
Below you will find a short but informative description of deploy engines implemented in Rally.
Available Deploy engines
------------------------
ExistingCloud
^^^^^^^^^^^^^
**Description**
This engine in fact does not deploy anything, but uses an existing OpenStack installation. It may be useful in case you have a preconfigured OpenStack deployment ready to launch benchmark scenarios.
**Configuration Example**
.. code-block:: none
{
"type": "ExistingCloud",
"auth_url": "http://192.168.122.22:5000/v2.0/",
"endpoint_type": "public",
"admin": {
"username": "admin",
"password": "password",
"tenant_name": "admin",
}
}
Or using keystone v3 API endpoint:
.. code-block:: none
{
"type": "ExistingCloud",
"auth_url": "http://localhost:5000/v3/",
"endpoint_type": "public",
"admin": {
"username": "engineer1",
"user_domain_name": "qa",
"project_name": "qa_admin_project",
"project_domain_name": "qa",
"password": "password",
"region_name": "RegionOne",
}
}
..
*endpoint_type* option will be used later for selecting access method to the cloud.
Users can select from "public", "internal", "admin" access methods.
All you should specify in the config is the OpenStack cloud endpoint: the auth_url and also admin credentials, including tenant name. Rally will use the specified admin account to manage temporary non-admin tenants and users exploited while launching benchmark scenarios.
DevstackEngine
^^^^^^^^^^^^^^
**Description**
This engine deploys a Devstack cloud using the given Devstack repository.
**Configuration Example**
.. code-block:: none
{
"type": "DevstackEngine",
"localrc": {
"ADMIN_PASSWORD": "secret",
"NOVA_REPO": "git://example.com/nova/",
...
},
"devstack_repo": "git://example.com/devstack/",
"type": {
"name": "${PROVIDER_NAME}",
...
}
}
The localrc field of the Devstack engine configuration will be used to initialize the Devstack's localrc file. As this deploy engine does not use an existing cloud, it also needs a concrete :ref:`server provider <server_providers>` specification: the type of the used provider *(${PROVIDER_NAME})*, followed by provider-specific fields configuration.
**Note**
More Deploy engines are to come in future releases, namely deploy engines for FUEL, Tripple-O etc. Stay tuned.

287
doc/source/implementation.rst
View File

@ -1,287 +0,0 @@
..
Copyright 2014 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.
.. _implementation:
Implementation
==============
Benchmark engine
----------------
The :mod:`rally.benchmark.engine` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.engine
:members:
:undoc-members:
:show-inheritance:
The :mod:`rally.benchmark.runners` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.runners
:members:
:undoc-members:
:show-inheritance:
The :mod:`rally.benchmark.context` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.context
:members:
:undoc-members:
:show-inheritance:
The :mod:`rally.benchmark.processing` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.processing
:members:
:undoc-members:
:show-inheritance:
Benchmark scenarios
-------------------
The :mod:`rally.benchmark.scenarios.utils` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.scenarios.utils
:members:
:undoc-members:
:show-inheritance:
The Cinder Scenarios
^^^^^^^^^^^^^^^^^^^^
The :mod:`rally.benchmark.scenarios.cinder.volumes` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.scenarios.cinder.volumes
:members:
:undoc-members:
:show-inheritance:
The :mod:`rally.benchmark.scenarios.cinder.utils` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.scenarios.cinder.utils
:members:
:undoc-members:
:show-inheritance:
The Keystone Scenarios
^^^^^^^^^^^^^^^^^^^^^^
The :mod:`rally.benchmark.scenarios.keystone.basic` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.scenarios.keystone.basic
:members:
:undoc-members:
:show-inheritance:
The :mod:`rally.benchmark.scenarios.keystone.utils` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.scenarios.keystone.utils
:members:
:undoc-members:
:show-inheritance:
The Nova Scenarios
^^^^^^^^^^^^^^^^^^
The :mod:`rally.benchmark.scenarios.nova.servers` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.scenarios.nova.servers
:members:
:undoc-members:
:show-inheritance:
The :mod:`rally.benchmark.scenarios.nova.utils` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.benchmark.scenarios.nova.utils
:members:
:undoc-members:
:show-inheritance:
Deploy engines
--------------
The :mod:`rally.deploy.engine` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.deploy.engine
:members:
:undoc-members:
:show-inheritance:
The DevStack Engine
^^^^^^^^^^^^^^^^^^^
The :mod:`rally.deploy.engines.devstack` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.deploy.engines.devstack
:members:
:undoc-members:
:show-inheritance:
The Dummy Engine
^^^^^^^^^^^^^^^^
The :mod:`rally.deploy.engines.existing` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.deploy.engines.existing
:members:
:undoc-members:
:show-inheritance:
Database
--------
Represents a high level database abstraction interface which is used as persistent
storage for Rally. The storage operations implemented in driver abstractions.
The :mod:`rally.db.api` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.db.api
:members:
:undoc-members:
:show-inheritance:
The SQLAlchemy Driver
^^^^^^^^^^^^^^^^^^^^^
The driver uses the sqlalchemy library and provides flexible range of supported
SQL storages.
The :mod:`rally.db.sqlalchemy.api` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.db.sqlalchemy.api
:members:
:undoc-members:
:show-inheritance:
The :mod:`rally.db.sqlalchemy.models` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.db.sqlalchemy.models
:members:
:undoc-members:
:show-inheritance:
Server providers
----------------
The :mod:`rally.deploy.serverprovider.provider` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.deploy.serverprovider.provider
:members:
:undoc-members:
:show-inheritance:
The Dummy Server Provider
^^^^^^^^^^^^^^^^^^^^^^^^^
The :mod:`rally.deploy.serverprovider.providers.dummy` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.deploy.serverprovider.providers.existing
:members:
:undoc-members:
:show-inheritance:
The OpenStack Server Provider
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The :mod:`rally.deploy.serverprovider.providers.openstack` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.deploy.serverprovider.providers.openstack
:members:
:undoc-members:
:show-inheritance:
The LXC Server Provider
^^^^^^^^^^^^^^^^^^^^^^^
The :mod:`rally.deploy.serverprovider.providers.lxc` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.deploy.serverprovider.providers.lxc
:members:
:undoc-members:
:show-inheritance:
The Virsh Server Provider
^^^^^^^^^^^^^^^^^^^^^^^^^
The :mod:`rally.deploy.serverprovider.providers.virsh` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.deploy.serverprovider.providers.virsh
:members:
:undoc-members:
:show-inheritance:
Objects
-------
Represents a high level abstraction of persistent database objects and
operations on them.
The :mod:`rally.objects.task` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.objects.task
:members:
:undoc-members:
:show-inheritance:
The :mod:`rally.objects.deploy` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.objects.deploy
:members:
:undoc-members:
:show-inheritance:
OpenStack Clients
-----------------
The :mod:`rally.osclients` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: rally.osclients
:members:
:undoc-members:
:show-inheritance:

3
doc/source/concepts.rst → doc/source/miscellaneous/concepts.rst
View File

@ -75,6 +75,7 @@ Note that inside each scenario configuration, the benchmark scenario is actually
.. _ScenariosDevelopment:
Developer's view
^^^^^^^^^^^^^^^^
@ -162,6 +163,7 @@ Also, all scenario runners can be provided (again, through the **"runner"** sect
.. _RunnersDevelopment:
Developer's view
^^^^^^^^^^^^^^^^
@ -257,6 +259,7 @@ In the example below, the **"users" context** specifies that the *"NovaServers.b
.. _ContextDevelopment:
Developer's view
^^^^^^^^^^^^^^^^

144
doc/source/server_providers.rst
View File

@ -1,144 +0,0 @@
..
Copyright 2014 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.
.. _server_providers:
Server providers
================
Introduction
------------
Server providers in Rally are typically used by :ref:`deploy engines <deploy_engines>` to manage virtual machines necessary for OpenStack deployment and its following benchmarking. The key feature of server providers is that they provide a **unified interface** for interacting with different **virtualization technologies** (LXS, Virsh etc.) and **cloud suppliers** (like Amazon).
Every server provider should implement the following basic interface:
..
**constructor**, which should take the **deployment** entity the provider should bind to and a **config** dictionary as its parameters;
..
**create_servers(image_uuid, type_id, amount)**, which should create the requested number of virtual machines of the given type using a specific image. The method should also return the list of created servers wrapped in special Server entities.
..
**destroy_servers()**, which should destroy all virtual machines previously created by the same server provider.
Below you will find a short but informative description of server providers implemented in Rally.
Available Server providers
--------------------------
ExistingServers
^^^^^^^^^^^^^^^
**Description**
This provider does nothing, but returns endpoints from configuration. This may be useful if you have specific software/hardware configuration ready to deploy OpenStack.
**Configuration Example**
.. code-block:: none
{
"type": "DevstackEngine",
"provider": {
"type": "ExistingServers",
"credentials": [{"user": "root", "host": "10.2.0.8"}]
}
}
VirshProvider
^^^^^^^^^^^^^
**Description**
This provider creates virtual machines on host provided by configuration.
**Configuration Examples**
Clone VM from pre-built template using virsh
.. code-block:: none
{
"type": "VirshProvider",
"connection": "user@host.net",
"template_name": "stack-01-devstack-template",
"template_user": "ubuntu",
"template_password": "password"
}
LxcProvider
^^^^^^^^^^^
**Description**
This provider creates lxc containers on host provided by another provider. Container is attached to the same network as host.
Works well with ubuntu-13.10 hosts.
**Configuration Example**
.. code-block:: none
{
"type": "LxcProvider",
"containers_per_host": 1,
"distribution": "ubuntu",
"ipv4_start_address": "192.168.1.43",
"ipv4_prefixlen": 16,
"host_provider": {
"type": "DummyProvider",
"credentials": [{"user": "root", "host": "192.168.1.42"}]
}
}
OpenStackProvider
^^^^^^^^^^^^^^^^^
**Description**
Provides VMs using existing OpenStack cloud.
**Configuration Example**
.. code-block:: none
{
"type": "OpenStackProvider",
"deployment_name": "Rally sample deployment",
"amount": 3,
"user": "admin",
"tenant": "admin",
"password": "secret",
"auth_url": "http://example.net:5000/v2.0",
"flavor_id": 2,
"image": {
"checksum": "75846dd06e9fcfd2b184aba7fa2b2a8d",
"url": "http://example.com/disk1.img",
"name": "Ubuntu Precise(added by rally)",
"format": "qcow2",
"userdata": "#cloud-config\r\n disable_root: false\r\n manage_etc_hosts: true\r\n"
}
}

1
doc/source/testing.rst
View File

@ -1 +0,0 @@
../../tests/README.rst

4
doc/source/tutorial/step_1_setting_up_env_and_running_benchmark_from_samples.rst
View File

@ -208,12 +208,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_3_adding_success_criteria_for_benchmarks>`):
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>`):
.. 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_sla>`).
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>`).
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**:

2
doc/source/tutorial/step_2_running_multple_benchmarks_in_a_single_task.rst
View File

@ -21,7 +21,7 @@ Step 2. Running multiple benchmarks in a single task
Rally input task syntax
-----------------------
Rally comes with a really great collection of :ref:`benchmark scenarios <tutorial_step_6_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_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:
.. code-block:: none

2
doc/source/tutorial/step_3_adding_success_criteria_for_benchmarks.rst
View File

@ -141,4 +141,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 the :ref:`the next section of our tutorial <tutorial_step_4_aborting_load_generation_on_sla_failure>`, 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_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.

4
doc/source/tutorial/step_8_task_templates.rst → doc/source/tutorial/step_4_task_templates.rst
View File

@ -13,9 +13,9 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_8_task_templates:
.. _tutorial_step_4_task_templates:
Step 8. Rally task templates
Step 4. Rally task templates
============================
Basic template syntax

4
doc/source/tutorial/step_4_aborting_load_generation_on_sla_failure.rst → doc/source/tutorial/step_5_aborting_load_generation_on_sla_failure.rst
View File

@ -13,9 +13,9 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_4_aborting_load_generation_on_sla_failure:
.. _tutorial_step_5_aborting_load_generation_on_sla_failure:
Step 4. Aborting load generation on success criteria failure
Step 5. 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 to big load was the major issue for production clouds, because Rally didn’t know how to stop the load until it was to late. Finally I am happy to say that we solved this issue.

4
doc/source/tutorial/step_5_working_with_multple_openstack_clouds.rst → doc/source/tutorial/step_6_working_with_multple_openstack_clouds.rst
View File

@ -13,9 +13,9 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_5_working_with_multple_openstack_clouds:
.. _tutorial_step_6_working_with_multple_openstack_clouds:
Step 5. Working with multiple OpenStack clouds
Step 6. 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.

4
doc/source/tutorial/step_6_discovering_more_benchmark_scenarios.rst → doc/source/tutorial/step_7_discovering_more_benchmark_scenarios.rst
View File

@ -13,9 +13,9 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_6_discovering_more_benchmark_scenarios:
.. _tutorial_step_7_discovering_more_benchmark_scenarios:
Step 6. Discovering more benchmark scenarios in Rally
Step 7. Discovering more benchmark scenarios in Rally
=====================================================
Scenarios in the Rally repository

4
doc/source/tutorial/step_7_deploying_openstack.rst → doc/source/tutorial/step_8_deploying_openstack.rst
View File

@ -13,9 +13,9 @@
License for the specific language governing permissions and limitations
under the License.
.. _tutorial_step_7_working_with_multple_openstack_clouds:
.. _tutorial_step_8_working_with_multple_openstack_clouds:
Step 7. Deploying OpenStack from Rally
Step 8. 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:

2
doc/user_stories/nova/boot_server.rst
View File

@ -39,7 +39,7 @@ Cluster
This cluster was created via Fuel Dashboard interface.
+----------------------+-----------------------------------------------------------------------------+
| Deployment | Custom build of `Mirantis OpenStack <https://software.mirantis.com/>`_ v5.1 |
| Deployment | Custom build of `Mirantis OpenStack <https://software.mirantis.com/>`_ v5.1 |
+----------------------+-----------------------------------------------------------------------------+
| OpenStack release | Icehouse |
+----------------------+-----------------------------------------------------------------------------+