Rally v0.10.0

Overview

Release date 10/20/2017
  • Ability to use OpenStack deployments without admin credentials
  • Better validation process of tasks
  • New task format (with an ability to set description for workloads)
  • New JSON report
  • ElasticSearch exporter
  • OSProfiler support
  • Restructure of configuration options.

Details

Command Line Interface

  • Introduce rally task import command for importing task results into database.
  • Extend tags support for tasks. Now you can specify several tags for a single task using –tag argument. Also filtering tasks by tags is now available.
  • Move DB category from rally-manage db to rally db and introduce rally db show command for printing the used connection string.

Deployments

This release we started a huge work related to simplification of deployment component of Rally. There is a good progress which includes several nice features:

  • The format. “ExistingCloud” deployment type covers 99.99% cases and is used as a base for all new things. Also, it will be extended to support different platforms soon. The new format looks like (for OpenStack case):

    {
    "openstack": {
        "admin": {
            "username": "admin",
            "password": "changeme",
            "tenant_name": "foo",
        },
        "auth_url": "https://example.com",
    }
}

  • admin user is optional in case of setting existing users. From the beginning, setting admin credentials was a required section of Rally deployment configuration. Even with introducing existing users feature, this behaviour left. Finally, we finished a big code refactoring and admin credential become optional section. If a set of plugins for particular workload doesn’t require admin user, you can launch this task at deployment without setting it.

    The information about the requirements of plugins you can find at Plugins Reference page (see Requires platform(s): section at the bottom of each plugin).

  • Originally, Rally project was designed to check performance of OpenStack and we succeeded in building awesome tool. We do not plan to stop and just want to inform about our future plans to expand a number of supported platforms. Subscribe to our GitHub organization to not miss new plugins.

Task component

  • The new task format is introduced. It includes a bunch of improvements, unification, etc. All the docs and samples will be updated soon.

    As for now, you can check a spec for this big change.

  • SLA failure_rate max=0 become a default if nothing else is specified.

  • Totally reworked atomic actions. The atomic actions now supports nested actions which allows to measure durations inside the scenario even more precise. You can find them in HTML report or in our new json report (see rally task report --json).

  • Generation of names for new resources takes care about particular workload id, so it helps to provide a better cleanup and prepare for new feature - disaster cleanup.

Plugins

We started supporting discovering plugins by entry-points, so you can easily deliver your custom plugins as a simple python package.

To make you package after-discoverable, you need to specify the proper entry-point at your setup.cfg file:

Deployment Engines:

Remove serverproviders & rarely used deployers

Unfortunately, seems like nobody is using deployers for deploying their clouds and mostly people would like just to execute their code.

  1. Remove server provides
  2. Remove engines that uses server providers

OpenStack clients:

  • Deprecate EC2 client. It wasn’t used in any of plugins and doesn’t support keystone v3
  • Move rally.osclients module to rally.plugins.openstack.oscliens

Scenarios:

The old way to describe scenario plugin via method is finally removed. Initially Rally scenario plugins were methods of special class, like below:

from rally.task import scenario

class SomeBasicClass(scenario.Scenario):

   @scenario.configure()
   def some_scenario(self, arg1):
       """An implementation of SomeBasicClass.foo scenario."""

   @scenario.configure()
   def another_scenario(self):
       """Implementation of another scenario, SomeBasicClass.bar."""

However to unify scenarios with other plugins we moved to model where plugin is class. It was done long time ago.

from rally.task import scenario

@scenario.configure(name="CustomName")
class Some(scenario.Scenario):

   def run(self, arg1):
       """An implementation of the scenario."""

We had a bunch of code that was used for transition and backward compatibility that we finally removed.

  • NEW!!
  • UPDATED!!
  • DELETED

Fuel and Nova-Network are not alive any more. So we removed those scenarios. If any of those scenarios a critical for you, please contact us.

Validators:

The validators refactoring was a long-term task which blocked us to abandon alignment to only OpenStack platform and requirements of setting admin credentials. In this release, we made a great progress and fixed a lot of issues and blockers which made possible to refactor validators. Now validation step is equal for all types of plugins (Scenario, SLA, Context, Hooks, Runners, etc).

The old way to add validator for scenario is deprecated. The new unified way looks like:

import time

from rally.common import validation
from rally.task import scenario

@validation.add("number", param_name="timeout", minval=0)
@scenario.configure(name="Foo.bar")
class FooScenario(scenario.Scenario):
    def run(self, timeout):
        time.sleep()

The old validators from rally.task.validators module is deprecated too, see equivalents which can be used with add decorator:

Fixed bugs

  • [plugins] JSON schema of servers context allows to transmit a list of nics in two formats. First one is a format that novaclient expects to see (each network should be represented like {"nic-id": "the id of the network"}). The second one is more user-friendly - just list of strings (each network should be represented just by id of the network). Unfortunately, the second case was not covered by our code base.

    Also, the first described format works in limited cases due to bad serialization.

    Launchpad bug-report #1695245

  • [deployment] ~/rally/.openrc not working for keystone v3

    Launchpad bug-report #1683820

  • [plugins] Failed to list volumes in case of missed name in the object.

  • [backported into 0.9.1][deployment] Credentials is not updated as soon as deployment is recreated. Need to call recreate request twice.

    Launchpad bug-report #1675271

  • [backported into 0.9.1][plugins] Scenario IronicNodes.create_and_list_node had a wrong check that list of all nodes contains newly created one.

  • [backported into 0.9.1][task][cleanup] Do not remove quotas in case of existing users

  • [backported into 0.9.1][task][cleanup] Various traces of neutron resources

  • [backported into 0.9.1][core] Keystone v3, authentication error for Rally users if the value of project_domain_name of admin user isn’t equal “default”

    Launchpad bug-report #1680837

  • [backported into 0.9.1][task] Scenario NovaHosts.list_and_get_hosts obtains hostname for all hosts. But it fails in some environments if host is not compute.

    Launchpad bug-report #1675254

  • [backported into 0.9.1][verification] Rally fails to run on systems on which python-virtualenv is not installed

    Launchpad bug-report #1678047

  • [backported into 0.9.1][verification] CLI rally verify rerun fails with TypeError due to wrong integration with Rally API.

  • [plugins] Rally fails while creating neutron router on the clouds where ext-gw-mode extension is not installed.

  • [plugins] Scenario CinderVolumes.create_nested_snapshots_and_attach_volume fails on a big load due to the fact that one server is used for several iterations. In such case we are facing 2 issues: the maximum number of volumes per VM is 26 (which is a number of available names for volumes); detaching volume of one iteration can block attaching of other iterations.

    Launchpad bug-report #1708160

Thanks

2 Everybody!