Rally on OpenStack summit in Vancouver

OpenStack summit  just had finished and it’s time to summarize all Rally events.

Using Rally for OpenStack certification at Scale!

It goes without saying that one of the most important things all OpenStack clouds from big to small is to be 100% sure that everything works as expected BEFORE taking on production workloads.

To ensure that production workloads will be successful, we can do a few key things:

  1. Generate real load test from “real” OpenStack users
  2. Collect and retain detailed execution data for examination and historical comparison
  3. Measure workload performance and failure rate against established SLAs to validate a deployment
  4. Visualize results in beautiful graphic detail

Rally can fully automate these steps for you and save dozens if not hundreds of hours.

(more…)

Read More

Rally v0.0.4 – What’s new?

Rally v0.0.4

Information

+------------------+-----------------+
| Commits          |       87        |
+------------------+-----------------+
| Bug fixes        |       21        |
+------------------+-----------------+
| Dev cycle        |     30 days     |
+------------------+-----------------+
| Release date     |   14/May/2015   |
+------------------+-----------------+

Details

This release contains new features, new benchmark plugins, bug fixes, various code and API improvements.

New Features & API changes

  • Rally now can generate load with users that already existNow one can use Rally for benchmarking OpenStack clouds that are using LDAP, AD or any other read-only keystone backend where it is not possible to create any users. To do this, one should set up the “users” section of the deployment configuration of the ExistingCloud type. This feature also makes it safer to run Rally against production clouds: when run from an isolated group of users, Rally won’t affect rest of the cloud users if something goes wrong.
  • New decorator @osclients.Clients.register can add new OpenStack clients at runtimeIt is now possible to add a new OpenStack client dynamically at runtime. The added client will be available from osclients.Clients at the module level and cached. Example:
       >>> from rally import osclients
       >>> @osclients.Clients.register("supernova")
       ... def another_nova_client(self):
       ...   from novaclient import client as nova
       ...   return nova.Client("2", auth_token=self.keystone().auth_token,
       ...                      **self._get_auth_info(password_key="key"))
       ...
       >>> clients = osclients.Clients.create_from_env()
       >>> clients.supernova().services.list()[:2]
       [, ]
    
  • Assert methods now available for scenarios and contextsThere is now a new FunctionalMixin class that implements basic unittest assert methods. The base.Context and base.Scenario classes inherit from this mixin, so now it is possible to use base.assertX() methods in scenarios and contexts.
  • Improved installation scriptThe installation script has been almost completely rewritten. After this change, it can be run from an unprivileged user, supports different database types, allows to specify a custom python binary, always asks confirmation before doing potentially dangerous actions, automatically install needed software if run as root, and also automatically cleans up the virtualenv and/or the downloaded repository if interrupted.

(more…)

Read More

The simplest way to use OpenStack python clients

OpenStack is great but as all young projects it has some UX issues. One of the most user facing is initialization of OpenStack python clients. Every OpenStack Service like Nova, Cinder, Glance have own.

Since the begging in Rally we have internal class that unifies initialization of all clients. Recently we merged patch that allows to init this class from environment variables, which makes it really simple to use OpenStack python clients. Take a look at code snippet below:

boris@ubuntu:~$ . devstack/openrc admin admin

boris@ubuntu:~$ python
>>> from rally import osclients
>>> clients = osclients.Clients.create_from_env()
>>> clients.nova().flavors.list()
[<Flavor: m1.tiny>, <Flavor: m1.small>, <Flavor: m1.medium>, <Flavor: m1.large>, <Flavor: m1.nano>, <Flavor: m1.heat>, <Flavor: m1.xlarge>, <Flavor: m1.micro>]

(more…)

Read More