Amended sphinx documents
Updated from https://wiki.openstack.org/wiki/Rally Change-Id: I520b08202910ad476447fa09ca0a5993fc1bffc5
This commit is contained in:
Oleh Anufriiev
parent
3609d51a14
commit
c4269ec970
@ -13,16 +13,16 @@
|
||||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
|
||||
.. _benchmark:
|
||||
.. _main_concepts:
|
||||
|
||||
Benchmark
|
||||
=========
|
||||
Main concepts of Rally
|
||||
======================
|
||||
|
||||
Benchmark Scenarios
|
||||
-------------------
|
||||
|
||||
Notion of benchmark scenarios
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Concept
|
||||
^^^^^^^
|
||||
|
||||
The concept of **benchmark scenarios** is a central one in Rally. Benchmark scenarios are what Rally actually uses to **test the performance of an OpenStack deployment**. They also play the role of main building blocks in the configurations of benchmark tasks. Each benchmark scenario performs a small **set of atomic operations**, thus testing some **simple use case**, usually that of a specific OpenStack project. For example, the **"NovaServers"** scenario group contains scenarios that use several basic operations available in **nova**. The **"boot_and_delete_server"** benchmark scenario from that group allows to benchmark the performance of a sequence of only **two simple operations**: it first **boots** a server (with customizable parameters) and then **deletes** it.
|
||||
|
||||
@ -105,14 +105,11 @@ In a toy example below, we define a scenario class *MyScenario* with one benchma
|
||||
|
||||
|
||||
|
||||
Benchmark engine
|
||||
Scenario runners
|
||||
----------------
|
||||
|
||||
The core classes responsible for the benchmarking mechanism, including
|
||||
the benchmark engine class, benchmark scenario runners and others.
|
||||
|
||||
Notion of scenario runners
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Concept
|
||||
^^^^^^^
|
||||
|
||||
**Scenario Runners** in Rally are entities that control the execution type and order of benchmark scenarios. They support different running **strategies for creating load on the cloud**, including simulating *concurrent requests* from different users, periodic load, gradually growing load and so on.
|
||||
|
||||
@ -214,8 +211,8 @@ It is possible to extend Rally with new Scenario Runner types, if needed. Basica
|
||||
Benchmark contexts
|
||||
------------------
|
||||
|
||||
Notion of contexts
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
Concept
|
||||
^^^^^^^
|
||||
|
||||
The notion of **contexts** in Rally is essentially used to define different types of **environments** in which benchmark scenarios can be launched. Those environments are usually specified by such parameters as the number of **tenants and users** that should be present in an OpenStack project, the **roles** granted to those users, extended or narrowed **quotas** and so on.
|
||||
|
||||
@ -1,41 +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:
|
||||
|
||||
Deploy
|
||||
======
|
||||
|
||||
Deployment engines
|
||||
------------------
|
||||
|
||||
One of the core entities in Rally architecture are the **Deploy engines**. The main 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 **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 **server providers**).
|
||||
|
||||
|
||||
|
||||
Server Providers
|
||||
----------------
|
||||
|
||||
**Server providers** in Rally are typically used by **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.
|
||||
128
doc/source/deploy_engines.rst
Normal file
128
doc/source/deploy_engines.rst
Normal file
@ -0,0 +1,128 @@
|
||||
..
|
||||
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",
|
||||
"endpoint": {
|
||||
"auth_url": "http://192.168.122.22:5000/v2.0/",
|
||||
"username": "admin",
|
||||
"password": "password",
|
||||
"tenant_name": "admin",
|
||||
"use_public_urls": True
|
||||
}
|
||||
}
|
||||
|
||||
Or using keystone v3 API endpoint:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
{
|
||||
"type": "ExistingCloud,
|
||||
"endpoint": {
|
||||
"auth_url": "http://localhost:5000/v3/,
|
||||
"username": "engineer1,
|
||||
"user_domain_name": "qa,
|
||||
"project_name": "qa_admin_project,
|
||||
"project_domain_name": "qa,
|
||||
"password": "password,
|
||||
"region_name": "RegionOne,
|
||||
"use_public_urls": False,
|
||||
"admin_port": 35357
|
||||
}
|
||||
}
|
||||
..
|
||||
|
||||
*use_public_urls* option will be used later for switching access method to the cloud.
|
||||
Because in some use-cases cloud may be accessible only by public endpoints.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
BIN
doc/source/images/Amqp_rpc_single_reply_queue.png
Normal file
BIN
doc/source/images/Amqp_rpc_single_reply_queue.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
BIN
doc/source/images/Rally-Actions.png
Normal file
BIN
doc/source/images/Rally-Actions.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 178 KiB |
BIN
doc/source/images/Rally-UseCases.png
Normal file
BIN
doc/source/images/Rally-UseCases.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 207 KiB |
BIN
doc/source/images/Rally_Architecture.png
Normal file
BIN
doc/source/images/Rally_Architecture.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 178 KiB |
BIN
doc/source/images/Rally_QA.png
Normal file
BIN
doc/source/images/Rally_QA.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 117 KiB |
BIN
doc/source/images/Rally_VM_list.png
Normal file
BIN
doc/source/images/Rally_VM_list.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 79 KiB |
BIN
doc/source/images/Rally_snapshot_vm.png
Normal file
BIN
doc/source/images/Rally_snapshot_vm.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 128 KiB |
113
doc/source/improve_rally.rst
Normal file
113
doc/source/improve_rally.rst
Normal file
@ -0,0 +1,113 @@
|
||||
..
|
||||
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.
|
||||
|
||||
|
||||
|
||||
.. _improve_rally:
|
||||
|
||||
Improve Rally
|
||||
=============
|
||||
|
||||
Main directions of work
|
||||
-----------------------
|
||||
|
||||
* **Benchmarks**. Improvements in the benchmarking engine & developing new benchmark scenarios.
|
||||
* **Deployments**. Making Rally able to support multiple cloud deployment facilities, e.g. Fuel.
|
||||
* **CLI**. Enriching the command line interface for Rally.
|
||||
* **API**. Work around making Rally to be a Benchmark-as-a-Service system & developing rally-pythonclient.
|
||||
* **Incubation**. Efforts to make Rally an integrated project in OpenStack.
|
||||
* **Share system**. Benchmark results visualization and paste.openstack.org-like sharing system.
|
||||
* **Tempest**. Integration of Tempest tests in Rally for deployment verification.
|
||||
|
||||
|
||||
Where to begin
|
||||
--------------
|
||||
|
||||
It is extremetly simple to participate in different Rally development lines mentioned above. The **Good for start** section of our `Trello board <https://trello.com/b/DoD8aeZy/rally>`_ contains a wide range of tasks perfectly suited for you to quickly and smoothly start contributing to Rally. As soon as you have chosen a task, just log in to Trello, join the corresponding card and move it to the **In progress** section.
|
||||
|
||||
The most Trello cards contain basic descriptions of what is to be done there; in case you have questions or want to share your ideas, be sure to contanct us at the ``#openstack-rally`` IRC channel on **irc.freenode.net**.
|
||||
|
||||
If you want to grasp a better understanding of several main design concepts used throughout the Rally code (such as **benchmark scenarios**, **contexts** etc.), please read this :ref:`article <main_concepts>`.
|
||||
|
||||
|
||||
How to contribute
|
||||
-----------------
|
||||
|
||||
1. You need a `Launchpad <https://launchpad.net/>`_ account and need to be joined to the `Openstack team <https://launchpad.net/openstack>`_. You can also join the `Rally team <https://launchpad.net/rally>`_ if you want to. Make sure Launchpad has your SSH key, Gerrit (the code review system) uses this.
|
||||
|
||||
2. Sign the CLA as outlined in section 3 of the `How To Contribute wiki page <https://wiki.openstack.org/wiki/HowToContribute#If_you.27re_a_developer>`_.
|
||||
|
||||
3. Tell git your details:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
git config --global user.name "Firstname Lastname"
|
||||
git config --global user.email "your_email@youremail.com"
|
||||
|
||||
4. Install git-review. This tool takes a lot of the pain out of remembering commands to push code up to Gerrit for review and to pull it back down to edit it. It is installed using:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
pip install git-review
|
||||
|
||||
Several Linux distributions (notably Fedora 16 and Ubuntu 12.04) are also starting to include git-review in their repositories so it can also be installed using the standard package manager.
|
||||
|
||||
5. Grab the Rally repository:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
git clone git@github.com:stackforge/rally.git
|
||||
|
||||
6. Checkout a new branch to hack on:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
git checkout -b TOPIC-BRANCH
|
||||
|
||||
7. Start coding
|
||||
|
||||
8. Run the test suite locally to make sure nothing broke, e.g.:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
tox
|
||||
|
||||
**(NOTE you should have installed tox<=1.6.1 )**
|
||||
|
||||
If you extend Rally with new functionality, make sure you also have provided unit tests for it.
|
||||
|
||||
9. Commit your work using:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
git commit -a
|
||||
|
||||
|
||||
Make sure you have supplied your commit with a neat commit message, containing a link to the corresponding blueprint / bug, if appropriate.
|
||||
|
||||
10. Push the commit up for code review using:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
git review -R
|
||||
|
||||
That is the awesome tool we installed earlier that does a lot of hard work for you.
|
||||
|
||||
11. Watch your email or `review site <http://review.openstack.org/>`_, it will automatically send your code for a battery of tests on our `Jenkins setup <http://jenkins.openstack.org/>`_ and the core team for the project will review your code. If there are any changes that should be made they will let you know.
|
||||
|
||||
12. When all is good the review site will automatically merge your code.
|
||||
|
||||
|
||||
(This tutorial is based on: http://www.linuxjedi.co.uk/2012/03/real-way-to-start-hacking-on-openstack.html)
|
||||
@ -13,27 +13,46 @@
|
||||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
|
||||
Welcome to Rally's documentation!
|
||||
What is Rally?
|
||||
=================================
|
||||
|
||||
Rally is a benchmarking tool for the community that is capable of performing
|
||||
specific, complex and reproducible tests for real deployment scenarios.
|
||||
If you are here, you are probably familiar with OpenStack and you also know that it's a really huge ecosystem of cooperative services. When something fails, performs slowly or doesn't scale, it's really hard to answer different questions on "what", "why" and "where" has happened. Another reason why you could be here is that you would like to build an OpenStack CI/CD system that will allow you to improve SLA, performance and stability of OpenStack continuously.
|
||||
|
||||
The OpenStack QA team mostly works on CI/CD that ensures that new patches don't break some specific single node installation of OpenStack. On the other hand it's clear that such CI/CD is only an indication and does not cover all cases (e.g. if a cloud works well on a single node installation it doesn't mean that it will continue to do so on a 1k servers installation under high load as well). Rally aims to fix this and help us to answer the question "How does OpenStack work at scale?". To make it possible, we are going to automate and unify all steps that are required for benchmarking OpenStack at scale: multi-node OS deployment, verification, benchmarking & profiling.
|
||||
|
||||
|
||||
Source Documentation
|
||||
--------------------
|
||||
.. image:: ./images/Rally-Actions.png
|
||||
:width: 50%
|
||||
:align: center
|
||||
|
||||
Contents:
|
||||
* Deploy engine is not yet another deployer of OpenStack, but just a pluggable mechanism that allows to unify & simplify work with different deployers like: DevStack, Fuel, Anvil on hardware/VMs that you have.
|
||||
* Verification - (work in progress) uses tempest to verify the functionality of a deployed OpenStack cloud. In future Rally will support other OS verifiers.
|
||||
* Benchmark engine - allows to create parameterized load on the cloud based on a big repository of benchmarks.
|
||||
|
||||
|
||||
Deeper in Rally:
|
||||
----------------
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
overview
|
||||
concepts
|
||||
deploy_engines
|
||||
server_providers
|
||||
verify
|
||||
installation
|
||||
usage
|
||||
|
||||
Development information:
|
||||
------------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
deploy
|
||||
verify
|
||||
benchmark
|
||||
cmds
|
||||
implementation
|
||||
|
||||
improve_rally
|
||||
rally_gatejob
|
||||
|
||||
Indices and tables
|
||||
------------------
|
||||
|
||||
166
doc/source/installation.rst
Normal file
166
doc/source/installation.rst
Normal file
@ -0,0 +1,166 @@
|
||||
..
|
||||
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.
|
||||
|
||||
.. _installation:
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
|
||||
Rally setup
|
||||
-----------
|
||||
|
||||
The simplest way to start using Rally is to install it together with OpenStack using DevStack. If you already have an existing OpenStack installation and/or don't want to install DevStack, then the preferable way to set up Rally would be to install it manually. Both types of installation are described below in full detail.
|
||||
|
||||
**Note: Running Rally on OSX is not advised as some pip dependencies will fail to install**.
|
||||
|
||||
Automated installation
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
**NOTE: Please ensure that you have installed either the Python 2.6 or the Python 2.7 version in the system that you are planning to install Rally**.
|
||||
|
||||
The installation script of Rally supports 2 installation methods:
|
||||
|
||||
* system-wide (default)
|
||||
* in a virtual environment using the virtualenv tool
|
||||
|
||||
|
||||
On the target system, get the source code of Rally:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
git clone https://git.openstack.org/stackforge/rally
|
||||
|
||||
**As root, or as a normal user using sudo**, execute the installation script. If you define the -v switch, Rally will be installed in a virtual environment, otherwise, it will be installed system-wide.
|
||||
|
||||
**Install system-wide**:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
./rally/install_rally.sh
|
||||
|
||||
**Or install in a virtual environment**:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
./rally/install_rally.sh -v
|
||||
|
||||
Now you are able to :ref:`use Rally <usage>`!
|
||||
|
||||
Rally with DevStack all in one installation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To install Rally with DevStack, you should first clone the corresponding repositories and copy the files necessary to integrate Rally with DevStack:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
git clone https://github.com/openstack-dev/devstack
|
||||
git clone https://github.com/stackforge/rally
|
||||
|
||||
To configure DevStack to run Rally:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
cp rally/contrib/devstack/lib/rally devstack/lib/
|
||||
cp rally/contrib/devstack/extras.d/70-rally.sh devstack/extras.d/
|
||||
cd devstack
|
||||
echo "enable_service rally" >> localrc
|
||||
|
||||
Finally, run DevStack as usually:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
./stack.sh
|
||||
|
||||
And finally you are able to :ref:`use Rally <usage>`!
|
||||
|
||||
|
||||
Manual installation
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Prerequisites
|
||||
"""""""""""""
|
||||
|
||||
Start with installing some requirements that Rally needs to be set up correctly. The specific requirements depend on the environment you are going to install Rally in:
|
||||
|
||||
**Ubuntu**
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get install libpq-dev git-core python-dev libevent-dev libssl-dev libffi-dev libsqlite3-dev
|
||||
curl -o /tmp/get-pip.py https://raw.github.com/pypa/pip/master/contrib/get-pip.py
|
||||
sudo python /tmp/get-pip.py
|
||||
sudo pip install pbr
|
||||
|
||||
**CentOS**
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
sudo yum install gcc git-core postgresql-libs python-devel libevent-devel openssl-devel libffi-devel sqlite
|
||||
#install pip on centos:
|
||||
curl -o /tmp/get-pip.py https://raw.github.com/pypa/pip/master/contrib/get-pip.py
|
||||
sudo python /tmp/get-pip.py
|
||||
sudo pip install pbr
|
||||
|
||||
**VirtualEnv**
|
||||
|
||||
Another option is to install Rally in virtualenv; you should then install this package, create a virtualenv and activate it:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
sudo pip install -U virtualenv
|
||||
virtualenv .venv
|
||||
. .venv/bin/activate # NOTE: Make sure that your current shell is either bash or zsh (otherwise it will fail)
|
||||
sudo pip install pbr
|
||||
|
||||
Installing Rally
|
||||
""""""""""""""""
|
||||
|
||||
The next step is to clone & install rally:
|
||||
|
||||
.. code-block: none
|
||||
|
||||
git clone https://github.com/stackforge/rally.git && cd rally
|
||||
sudo python setup.py install
|
||||
|
||||
Now you are ready to configure Rally (in order for it to be able to use the database):
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
sudo mkdir /etc/rally
|
||||
sudo cp etc/rally/rally.conf.sample /etc/rally/rally.conf
|
||||
sudo vim /etc/rally/rally.conf
|
||||
# Change the "connection" parameter, For example to this:
|
||||
connection="sqlite:////a/path/here/rally.sqlite"
|
||||
|
||||
After the installation step has been completed, you need to create the Rally database:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
rally-manage db recreate
|
||||
|
||||
And finally you are able to :ref:`use Rally <usage>`!
|
||||
|
||||
|
||||
Running Rally's Unit Tests
|
||||
--------------------------
|
||||
|
||||
Rally should be tested with tox, but is not compatible with the current version of tox, so install tox 1.6.1 then run it.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
pip install 'tox<=1.6.1'
|
||||
tox
|
||||
131
doc/source/overview.rst
Normal file
131
doc/source/overview.rst
Normal file
@ -0,0 +1,131 @@
|
||||
..
|
||||
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.
|
||||
|
||||
.. _overview:
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
Before diving deep in Rally architecture let's take a look at 3 major high level Rally Use Cases:
|
||||
|
||||
.. image:: ./images/Rally-UseCases.png
|
||||
:width: 50%
|
||||
:align: center
|
||||
|
||||
|
||||
Typical cases where Rally aims to help are:
|
||||
|
||||
1. Automate measuring & profiling focused on how new code changes affect the OS performance;
|
||||
2. Using Rally profiler to detect scaling & performance issues;
|
||||
3. Investigate how different deployments affect the OS performance:
|
||||
* Find the set of suitable OpenStack deployment architectures;
|
||||
* Create deployment specifications for different loads (amount of controllers, swift nodes, etc.);
|
||||
4. Automate the search for hardware best suited for particular OpenStack cloud;
|
||||
5. Automate the production cloud specification generation:
|
||||
* Determine terminal loads for basic cloud operations: VM start & stop, Block Device create/destroy & various OpenStack API methods;
|
||||
* Check performance of basic cloud operations in case of different loads.
|
||||
|
||||
|
||||
Architecture
|
||||
------------
|
||||
|
||||
Usually OpenStack projects are as-a-Service, so Rally provides this approach and a CLI driven approach that does not require a daemon:
|
||||
|
||||
1. Rally as-a-Service: Run rally as a set of daemons that present Web UI (work in progress) so 1 RaaS could be used by whole team.
|
||||
2. Rally as-an-App: Rally as a just lightweight CLI app (without any daemons), that makes it simple to develop & much more portable.
|
||||
|
||||
|
||||
How is this possible? Take a look at diagram below:
|
||||
|
||||
.. image:: ./images/Rally_Architecture.png
|
||||
:width: 50%
|
||||
:align: center
|
||||
|
||||
So what is behind Rally?
|
||||
|
||||
|
||||
Rally Components
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Rally consists of 4 main components:
|
||||
|
||||
1. **Server Providers** - provide servers (virtual servers), with ssh access, in one L3 network.
|
||||
2. **Deploy Engines** - deploy OpenStack cloud on servers that are presented by Server Providers
|
||||
3. **Verification** - component that runs tempest (or another pecific set of tests) against a deployed cloud, collects results & presents them in human readable form.
|
||||
4. **Benchmark engine** - allows to write parameterized benchmark scenarios & run them against the cloud.
|
||||
|
||||
|
||||
But **why** does Rally need these components?
|
||||
It becomes really clear if we try to imagine: how I will benchmark cloud at Scale, if ...
|
||||
|
||||
.. image:: ./images/Rally_QA.png
|
||||
:align: center
|
||||
:width: 50%
|
||||
|
||||
|
||||
|
||||
Rally in action
|
||||
---------------
|
||||
|
||||
How amqp_rpc_single_reply_queue affects performance
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To show Rally's capabilities and potential we used NovaServers.boot_and_destroy scenario to see how amqp_rpc_single_reply_queue option affects VM bootup time. Some time ago it was `shown <https://docs.google.com/file/d/0B-droFdkDaVhVzhsN3RKRlFLODQ/edit?pli=1>`_ that cloud performance can be boosted by setting it on so naturally we decided to check this result. To make this test we issued requests for booting up and deleting VMs for different number of concurrent users ranging from one to 30 with and without this option set. For each group of users a total number of 200 requests was issued. Averaged time per request is shown below:
|
||||
|
||||
.. image:: ./images/Amqp_rpc_single_reply_queue.png
|
||||
:width: 50%
|
||||
:align: center
|
||||
|
||||
So apparently this option affects cloud performance, but not in the way it was thought before.
|
||||
|
||||
|
||||
Performance of Nova instance list command
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
**Context**: 1 OpenStack user
|
||||
|
||||
**Scenario**: 1) boot VM from this user 2) list VM
|
||||
|
||||
**Runner**: Repeat 200 times.
|
||||
|
||||
As a result, on every next iteration user has more and more VMs and performance of VM list is degrading quite fast:
|
||||
|
||||
.. image:: ./images/Rally_VM_list.png
|
||||
:width: 50%
|
||||
:align: center
|
||||
|
||||
Complex scenarios & detailed information
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
For example NovaServers.snapshot contains a lot of "atomic" actions:
|
||||
|
||||
1. boot VM
|
||||
2. snapshot VM
|
||||
3. delete VM
|
||||
4. boot VM from snapshot
|
||||
5. delete VM
|
||||
6. delete snapshot
|
||||
|
||||
Fortunately Rally collects information about duration of all these operation for every iteration.
|
||||
|
||||
As a result we are generating beautiful graph image:: Rally_snapshot_vm.png
|
||||
|
||||
.. image:: ./images/Rally_snapshot_vm.png
|
||||
:width: 50%
|
||||
:align: center
|
||||
|
||||
113
doc/source/rally_gatejob.rst
Normal file
113
doc/source/rally_gatejob.rst
Normal file
@ -0,0 +1,113 @@
|
||||
..
|
||||
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.
|
||||
|
||||
|
||||
.. _rally_gatejob:
|
||||
|
||||
Rally gates
|
||||
===========
|
||||
|
||||
How to create custom rally-gate job
|
||||
-----------------------------------
|
||||
|
||||
|
||||
To create rally-gate job, you should create rally-scenarios directory at the root of your project.
|
||||
|
||||
Normally this directory contains only {projectname}.yaml, but easily can be added more scenarios and jobs.
|
||||
|
||||
To {projectname}.yaml was ran on gate, you need to add "rally-jobs" to "jobs" section of projects.yaml in openstack-infra/config.
|
||||
|
||||
For example in glance project:
|
||||
|
||||
modules/openstack_project/files/jenkins_job_builder/config/projects.yaml:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
- project:
|
||||
name: glance
|
||||
github-org: openstack
|
||||
node: bare-precise
|
||||
tarball-site: tarballs.openstack.org
|
||||
doc-publisher-site: docs.openstack.org
|
||||
|
||||
jobs:
|
||||
- python-jobs
|
||||
- python-havana-bitrot-jobs
|
||||
- openstack-publish-jobs
|
||||
- translation-jobs
|
||||
- rally-jobs
|
||||
|
||||
|
||||
and add check-rally-dsvm-{projectname} to modules/openstack_project/files/zuul/layout.yaml:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
- name: openstack/glance
|
||||
template:
|
||||
- name: python-jobs
|
||||
- name: openstack-server-publish-jobs
|
||||
- name: periodic-havana
|
||||
- name: check-requirements
|
||||
- name: integrated-gate
|
||||
check:
|
||||
- check-devstack-dsvm-cells
|
||||
- check-tempest-dsvm-postgres-full
|
||||
- gate-tempest-dsvm-large-ops
|
||||
- gate-tempest-dsvm-neutron-large-ops
|
||||
- check-rally-dsvm-glance
|
||||
|
||||
|
||||
To add one more scenario and job, you need to add {scenarioname}.yaml file here, and check-rally-dsvm-{scenarioname} in projects.yaml. For example:
|
||||
|
||||
add rally-scenarios/myscenario.yaml to rally-scenarios directory in you project
|
||||
|
||||
and modules/openstack_project/files/jenkins_job_builder/config/projects.yaml:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
- project:
|
||||
name: glance
|
||||
github-org: openstack
|
||||
node: bare-precise
|
||||
tarball-site: tarballs.openstack.org
|
||||
doc-publisher-site: docs.openstack.org
|
||||
|
||||
jobs:
|
||||
- python-jobs
|
||||
- python-havana-bitrot-jobs
|
||||
- openstack-publish-jobs
|
||||
- translation-jobs
|
||||
- rally-jobs
|
||||
- 'check-rally-dsvm-{name}':
|
||||
name: myscenario
|
||||
|
||||
and add check-rally-dsvm-myscenario to modules/openstack_project/files/zuul/layout.yaml:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
- name: openstack/glance
|
||||
template:
|
||||
- name: python-jobs
|
||||
- name: openstack-server-publish-jobs
|
||||
- name: periodic-havana
|
||||
- name: check-requirements
|
||||
- name: integrated-gate
|
||||
check:
|
||||
- check-devstack-dsvm-cells
|
||||
- check-tempest-dsvm-postgres-full
|
||||
- gate-tempest-dsvm-large-ops
|
||||
- gate-tempest-dsvm-neutron-large-ops
|
||||
- check-rally-dsvm-myscenario
|
||||
|
||||
144
doc/source/server_providers.rst
Normal file
144
doc/source/server_providers.rst
Normal file
@ -0,0 +1,144 @@
|
||||
..
|
||||
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"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
276
doc/source/usage.rst
Normal file
276
doc/source/usage.rst
Normal file
@ -0,0 +1,276 @@
|
||||
..
|
||||
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.
|
||||
|
||||
.. _usage:
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
Usage demo
|
||||
----------
|
||||
|
||||
**NOTE**: Throughout this demo, we assume that you have a configured :ref:`Rally installation <installation>` and an already existing OpenStack deployment has keystone available at <KEYSTONE_AUTH_URL>.
|
||||
|
||||
|
||||
Step 1. Deployment initialization (use existing cloud)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
First, you have to provide Rally with an Openstack deployment it is going to benchmark. This is done through deployment **configuration files**. The actual deployment can be either created by Rally (see /doc/samples for configuration examples) or, as in our example, an already existing one. The configuration file (let's call it **existing.json**) should contain the deployment strategy (in our case, the deployment will be performed by the so called **"ExistingCloud"**, since the deployment is ready to use) and some specific parameters (for the ExistingCloud, an endpoint with administrator permissions):
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
{
|
||||
"type": "ExistingCloud",
|
||||
"endpoint": {
|
||||
"auth_url": <KEYSTONE_AUTH_URL>,
|
||||
"username": <ADMIN_USER_NAME>,
|
||||
"password": <ADMIN_PASSWORD>,
|
||||
"tenant_name": <ADMIN_TENANT>
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
To register this deployment in Rally, use the **deployment create** command:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ rally deployment create --filename=existing.json --name=existing
|
||||
+---------------------------+----------------------------+----------+------------------+
|
||||
| uuid | created_at | name | status |
|
||||
+---------------------------+----------------------------+----------+------------------+
|
||||
| <Deployment UUID> | 2014-02-15 22:00:28.270941 | existing | deploy->finished |
|
||||
+---------------------------+----------------------------+----------+------------------+
|
||||
Using deployment : <Deployment UUID>
|
||||
|
||||
|
||||
Note the last line in the output. It says that the just created deployment is now used by Rally; that means that all the benchmarking operations from now on are going to be performed on this deployment. In case you want to switch to another deployment, execute the **use deployment** command:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ rally use deployment --deploy-id=<Another deployment UUID>
|
||||
Using deployment : <Another deployment UUID>
|
||||
|
||||
|
||||
Finally, the **deployment check** command enables you to verify that your current deployment is healthy and ready to be benchmarked:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ rally deployment check
|
||||
+----------+-----------+-----------+
|
||||
| services | type | status |
|
||||
+----------+-----------+-----------+
|
||||
| nova | compute | Available |
|
||||
| cinderv2 | volumev2 | Available |
|
||||
| novav3 | computev3 | Available |
|
||||
| s3 | s3 | Available |
|
||||
| glance | image | Available |
|
||||
| cinder | volume | Available |
|
||||
| ec2 | ec2 | Available |
|
||||
| keystone | identity | Available |
|
||||
+----------+-----------+-----------+
|
||||
|
||||
Step 2. Benchmarking
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Now that we have a working and registered deployment, we can start benchmarking it. Again, the sequence of benchmark scenarios to be launched by Rally should be specified in a **benchmark task configuration file**. Note that there is already a set of nice benchmark tasks examples in *doc/samples/tasks/* (assuming that you are in the Rally root directory). The natural thing would be just to try one of these sample benchmark tasks, say, the one that boots and deletes multiple servers (*doc/samples/tasks/nova/boot-and-delete.json*). To start a benchmark task, run the task start command:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
ubuntu@tempeste-test:~$ rally -v task start rally/doc/samples/tasks/nova/boot-and-delete.json
|
||||
=============================================================================================
|
||||
Task 392c803b-37fd-4915-9732-3523f4252e9b is started
|
||||
--------------------------------------------------------------------------------
|
||||
2014-03-20 06:17:39.994 27502 INFO rally.benchmark.engine [-] Task 392c803b-37fd-4915-9732-3523f4252e9b | Starting: Check cloud.
|
||||
2014-03-20 06:17:40.123 27502 INFO rally.benchmark.engine [-] Task 392c803b-37fd-4915-9732-3523f4252e9b | Completed: Check cloud.
|
||||
2014-03-20 06:17:40.123 27502 INFO rally.benchmark.engine [-] Task 392c803b-37fd-4915-9732-3523f4252e9b | Starting: Task validation.
|
||||
2014-03-20 06:17:40.133 27502 INFO rally.benchmark.engine [-] Task 392c803b-37fd-4915-9732-3523f4252e9b | Starting: Task validation of scenarios names.
|
||||
2014-03-20 06:17:40.137 27502 INFO rally.benchmark.engine [-] Task 392c803b-37fd-4915-9732-3523f4252e9b | Completed: Task validation of scenarios names.
|
||||
2014-03-20 06:17:40.138 27502 INFO rally.benchmark.engine [-] Task 392c803b-37fd-4915-9732-3523f4252e9b | Starting: Task validation of syntax.
|
||||
2014-03-20 06:17:40.140 27502 INFO rally.benchmark.engine [-] Task 392c803b-37fd-4915-9732-3523f4252e9b | Completed: Task validation of syntax.
|
||||
2014-03-20 06:17:40.140 27502 INFO rally.benchmark.engine [-] Task 392c803b-37fd-4915-9732-3523f4252e9b | Starting: Task validation of semantic.
|
||||
2014-03-20 06:17:41.098 27502 ERROR glanceclient.common.http [-] Request returned failure status.
|
||||
|
||||
================================================================================
|
||||
Task 392c803b-37fd-4915-9732-3523f4252e9b is failed.
|
||||
--------------------------------------------------------------------------------
|
||||
<class 'rally.exceptions.InvalidBenchmarkConfig'>
|
||||
Task config is invalid.
|
||||
Benchmark NovaServers.boot_and_delete_server has wrong configuration of args at position 0: {'image_id': '73257560-c59b-4275-a1ec-ab140e5b9979', 'flavor_id': 1}
|
||||
Reason: Image with id '73257560-c59b-4275-a1ec-ab140e5b9979' not found
|
||||
|
||||
For more details run:
|
||||
rally -vd task detailed 392c803b-37fd-4915-9732-3523f4252e9b
|
||||
|
||||
This attempt, however, will most likely fail because of an **input arguments validation error** (due to a non-existing image name). The thing is that the benchmark scenario that boots a server needs to do that using a concrete image available in the OpenStack deployment. In prior iterations of Rally, the images were denoted by UUID (such as "flavor_id", "image_id", etc). Now, these resources are simply denoted by name.
|
||||
|
||||
To get started, make a local copy of the sample benchmark task:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
cp doc/samples/tasks/nova/boot-and-delete.json my-task.json
|
||||
|
||||
|
||||
and then edit it with the resource names from your OpenStack installation:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
{
|
||||
"NovaServers.boot_and_delete_server": [
|
||||
{
|
||||
"args": {
|
||||
"flavor": {
|
||||
"name": "m1.tiny"
|
||||
},
|
||||
"image": {
|
||||
"name": "CirrOS 0.3.1 (x86_64)"
|
||||
}
|
||||
},
|
||||
"runner": {
|
||||
"type": "constant",
|
||||
"times": 10,
|
||||
"concurrency": 2
|
||||
},
|
||||
"context": {
|
||||
"users": {
|
||||
"tenants": 3,
|
||||
"users_per_tenant": 2
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
|
||||
To obtain proper image name and flavor name, you can use the subcommand show of rally.
|
||||
|
||||
let's get a proper image name:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ rally show images
|
||||
+--------------------------------------+-----------------------+-----------+
|
||||
| UUID | Name | Size (B) |
|
||||
+--------------------------------------+-----------------------+-----------+
|
||||
| 8dfd6098-0c26-4cb5-8e77-1ecb2db0b8ae | CentOS 6.5 (x86_64) | 344457216 |
|
||||
| 2b8d119e-9461-48fc-885b-1477abe2edc5 | CirrOS 0.3.1 (x86_64) | 13147648 |
|
||||
+--------------------------------------+-----------------------+-----------+
|
||||
|
||||
|
||||
and a proper flavor name:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ rally show flavors
|
||||
+---------------------+-----------+-------+----------+-----------+-----------+
|
||||
| ID | Name | vCPUs | RAM (MB) | Swap (MB) | Disk (GB) |
|
||||
+---------------------+-----------+-------+----------+-----------+-----------+
|
||||
| 1 | m1.tiny | 1 | 512 | | 1 |
|
||||
| 2 | m1.small | 1 | 2048 | | 20 |
|
||||
| 3 | m1.medium | 2 | 4096 | | 40 |
|
||||
| 4 | m1.large | 4 | 8192 | | 80 |
|
||||
| 5 | m1.xlarge | 8 | 16384 | | 160 |
|
||||
+---------------------+-----------+-------+----------+-----------+-----------+
|
||||
|
||||
|
||||
After you've edited the **my-task.json** file, you can run this benchmark task again. This time, let's also use the --verbose parameter that will allow us to retrieve more logging from Rally while it performs benchmarking:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ rally -v task start my-task.json --tag my_task
|
||||
|
||||
================================================================================
|
||||
Task my_task 87eb8ff3-07f9-4941-b1be-63e707aceb1e is started
|
||||
--------------------------------------------------------------------------------
|
||||
2014-03-20 06:26:36.431 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Starting: Check cloud.
|
||||
2014-03-20 06:26:36.555 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Completed: Check cloud.
|
||||
2014-03-20 06:26:36.555 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Starting: Task validation.
|
||||
2014-03-20 06:26:36.564 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Starting: Task validation of scenarios names.
|
||||
2014-03-20 06:26:36.568 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Completed: Task validation of scenarios names.
|
||||
2014-03-20 06:26:36.568 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Starting: Task validation of syntax.
|
||||
2014-03-20 06:26:36.571 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Completed: Task validation of syntax.
|
||||
2014-03-20 06:26:36.571 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Starting: Task validation of semantic.
|
||||
2014-03-20 06:26:37.316 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Completed: Task validation of semantic.
|
||||
2014-03-20 06:26:37.316 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Completed: Task validation.
|
||||
2014-03-20 06:26:37.316 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Starting: Benchmarking.
|
||||
2014-03-20 06:26:41.596 27820 INFO rally.benchmark.runners.base [-] ITER: 0 START
|
||||
2014-03-20 06:26:41.596 27821 INFO rally.benchmark.runners.base [-] ITER: 1 START
|
||||
2014-03-20 06:26:46.105 27820 INFO rally.benchmark.runners.base [-] ITER: 0 END: Error <class 'rally.exceptions.GetResourceNotFound'>: Resource not found: `404`
|
||||
2014-03-20 06:26:46.105 27820 INFO rally.benchmark.runners.base [-] ITER: 2 START
|
||||
2014-03-20 06:26:46.451 27821 INFO rally.benchmark.runners.base [-] ITER: 1 END: Error <type 'exceptions.AttributeError'>: status
|
||||
2014-03-20 06:26:46.452 27821 INFO rally.benchmark.runners.base [-] ITER: 3 START
|
||||
2014-03-20 06:26:46.497 27820 INFO rally.benchmark.runners.base [-] ITER: 2 END: Error <class 'novaclient.exceptions.NotFound'>: Instance could not be found (HTTP 404) (Request-ID: req-dfd372e9-728d-49ca-87e1-54cbf593b2be)
|
||||
2014-03-20 06:26:46.497 27820 INFO rally.benchmark.runners.base [-] ITER: 4 START
|
||||
2014-03-20 06:26:53.274 27821 INFO rally.benchmark.runners.base [-] ITER: 3 END: OK
|
||||
2014-03-20 06:26:53.275 27821 INFO rally.benchmark.runners.base [-] ITER: 5 START
|
||||
2014-03-20 06:26:53.709 27820 INFO rally.benchmark.runners.base [-] ITER: 4 END: OK
|
||||
2014-03-20 06:26:53.710 27820 INFO rally.benchmark.runners.base [-] ITER: 6 START
|
||||
2014-03-20 06:26:59.942 27821 INFO rally.benchmark.runners.base [-] ITER: 5 END: OK
|
||||
2014-03-20 06:26:59.943 27821 INFO rally.benchmark.runners.base [-] ITER: 7 START
|
||||
2014-03-20 06:27:00.601 27820 INFO rally.benchmark.runners.base [-] ITER: 6 END: OK
|
||||
2014-03-20 06:27:00.601 27820 INFO rally.benchmark.runners.base [-] ITER: 8 START
|
||||
2014-03-20 06:27:06.635 27821 INFO rally.benchmark.runners.base [-] ITER: 7 END: OK
|
||||
2014-03-20 06:27:06.635 27821 INFO rally.benchmark.runners.base [-] ITER: 9 START
|
||||
2014-03-20 06:27:07.414 27820 INFO rally.benchmark.runners.base [-] ITER: 8 END: OK
|
||||
2014-03-20 06:27:13.311 27821 INFO rally.benchmark.runners.base [-] ITER: 9 END: OK
|
||||
2014-03-20 06:27:14.302 27812 WARNING rally.benchmark.context.secgroup [-] Unable to delete secgroup: 43
|
||||
2014-03-20 06:27:14.336 27812 WARNING rally.benchmark.context.secgroup [-] Unable to delete secgroup: 45
|
||||
2014-03-20 06:27:14.336 27812 INFO rally.benchmark.context.cleaner [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Starting: Cleanup users resources.
|
||||
2014-03-20 06:27:25.498 27812 INFO rally.benchmark.context.cleaner [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Completed: Cleanup users resources.
|
||||
2014-03-20 06:27:25.498 27812 INFO rally.benchmark.context.cleaner [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Starting: Cleanup admin resources.
|
||||
2014-03-20 06:27:25.689 27812 INFO rally.benchmark.context.cleaner [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Completed: Cleanup admin resources.
|
||||
2014-03-20 06:27:26.092 27812 INFO rally.benchmark.engine [-] Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e | Completed: Benchmarking.
|
||||
|
||||
================================================================================
|
||||
Task 87eb8ff3-07f9-4941-b1be-63e707aceb1e is finished.
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
test scenario NovaServers.boot_and_delete_server
|
||||
args position 0
|
||||
args values:
|
||||
{u'args': {u'flavor_id': 1,
|
||||
u'image_id': u'976dfd41-d8d5-4688-a8c1-8f196316d8b9'},
|
||||
u'context': {u'users': {u'tenants': 3, u'users_per_tenant': 2}},
|
||||
u'runner': {u'concurrency': 2, u'times': 10, u'type': u'continuous'}}
|
||||
+---------------------+-----------+-----------+-----------+---------------+---------------+---------+-------+
|
||||
| action | min (sec) | avg (sec) | max (sec) | 90 percentile | 95 percentile | success | count |
|
||||
+---------------------+-----------+-----------+-----------+---------------+---------------+---------+-------+
|
||||
| nova.boot_server | 0.480 | 0.501 | 0.521 | 0.521 | 0.521 | 100.0% | 10 |
|
||||
| nova.delete_server | 0.185 | 0.189 | 0.195 | 0.194 | 0.194 | 70.0% | 10 |
|
||||
| total | 0.666 | 0.690 | 0.715 | 0.715 | 0.715 | 70.0% | 10 |
|
||||
+---------------------+-----------+-----------+-----------+---------------+---------------+---------+-------+
|
||||
|
||||
HINTS:
|
||||
* To plot HTML graphics with this data, run:
|
||||
rally task plot2html 87eb8ff3-07f9-4941-b1be-63e707aceb1e --out output.html
|
||||
|
||||
* To get raw JSON output of task results, run:
|
||||
rally task results 87eb8ff3-07f9-4941-b1be-63e707aceb1e
|
||||
|
||||
Available Rally facilities
|
||||
--------------------------
|
||||
|
||||
To be able to run complex benchmark scenarios on somewhat more sophisticated OpenStack deployment types, you should familiarize yourself with more **deploy engines, server providers** and **benchmark scenarios** available in Rally.
|
||||
|
||||
..
|
||||
|
||||
List of available Deploy engines (including their description and usage examples): :ref:`Deploy engines <deploy_engines>`
|
||||
|
||||
..
|
||||
|
||||
List of available Server providers (including their description and usage examples): :ref:`Server providers <server_providers>`
|
||||
|
||||
..
|
||||
|
||||
List of available Benchmark scenarios (including their description and usage examples): :ref:`Benchmark scenarios <benchmark_scenarios>`
|
||||
Loading…
x
Reference in New Issue
Block a user