rally task start命令代码及task配置文件分析

简介：本文首先介绍了task配置文件中各参数含义，其次分析了rally运行task的代码逻辑，即对应命令行命令：rally task start --task xxx.json。最后分析rally实际测试的场景代码。

rally task配置文件

Rally本身提供了一些task配置文件，用于提供测试用例中所需的信息包括场景测试中所传入的参数、运行方式是并行还是串行，context等信息。Rally本身提供的task 配置文件在rally/samples/task/scenarios/目录下。

# Rally task start boot-and-delete.json {         "NovaServers.boot_and_delete_server": [             {                 "args": {                     ...                 },                 "runner": {                     ...                 },                 "context": {                     “users”:{} //generating temporary users/tenants for benchmarks. “networks”:{}...                 },                 "sla": {                     "max_seconds_per_iteration": 10,                     "failure_rate": {                         "max": 25                     }                 }             }         ] }

 

其中，args提供测试用例使用的类型方法的参数，context提供运行测试用例的上下文环境变量信息，包括模拟几个用户同时测试、租户情况等；quotas指定测试中涉及到资源的配额限制，runner提供测试的运行器情况，比如，并发测试、串行测试，等等。

Rally支持的runner方式：

rally目前支持4种runner类型，通过task配置文件中runner参数进行区分，包括：constant、constant_for_duration、rps、serial。

1、   constant方式，是利用multiprocessing的Pool方式创建一个进程池，池中的进程数量等于runner的配置参数concurrency，执行每个task时，由池中的所有进程同时测试、模拟多用户并发访问的情况。constant方式中要求提供参数times，用于指定一个task中执行测试用例的次数。

2、   constant_for_duration方式，与constant相似，也是构建一个进程池实现并发测试，区别在于，constant_for_duration方式要求额外提供一个参数duration，但是没有参数times。该参数用于指明执行测试的时间， rally一直执行task指定的测试用例，直到达到duration规定的时间长度，任务结束；

3、   rps方式，测试任务平均分配到每个processer上，通过对每个process创建thread实现高并发测试。不同于前两种方式（使用multiprocessing.Pool 构建进程池），rps方式使用multiprocessing.Process构建执行task的worker，每个worker执行测试次数的总和是配置中的times，每个worker的rps总和是配置中rps。workers的数量由times和运行rally测试的主机上实际processer数量的最小值确定，times平均分配到每个worker上。

4、   serial方式，是使用一个process串行的执行测试。

rally task-start命令执行流程

1.     由命令行发起start_task的任务请求：

a)       命令行命令：rally task start --task test.json--deployment deployment_uuid --tag task_tag。其中，

b)       --task参数必选参数，无默认值（必须输入），后跟的test.json对应执行task的配置文件路径；

c)        --deployment必选参数，有默认值（可以不输入），用于指定使用rally哪一个部署，如果不指定该参数，自动使用默认的deployment（）；

d)       --tag可选参数，用于为当前的task设置标签（task执行完成后，可以根据标签进行过滤）

e)       命令行执行task的代码:

cmd.commands.task.TaskCommands.start_task

在task执行完成之后，汇总result信息，并打印输出

 

1、创建的engine对象执行run方法：

l  Task validation

验证配置中提供的待测试方法是scenario方法;

验证配置文件中的context配置项是否正确;

验证配置文件的句法正确;

l  遍历配置文件中的每个待测试scenario类型方法

遍历每个待测试scenario类型方法的配置，执行测试。

l  get-runer()获得配置中的runner对象

l  prepare_context()准备测试运行中使用的context，在配置文件提供context基础上补充：task、admin、scenario_name等属性。

l  执行runer对象的_run_scenario方法，以ConstantScenarioRunner类型（配置文件中runner的type设置成constant）为例。从配置中获得timeout、concurrency、times等参数。创建multiprocessing的处理池，processor的数量是concurrency，按照配置中指定的测试次数生成benchmark.runners.base._run_scenario_once方法的测试序列。

依次执行上一步生成序列中的测试，每个测试即为对目标scenario类型方法的依次调用，并对执行结果进行统计相应统计。返回测试的运行时间，等待线程执行完成后，终止线程。

Rally脚本分析

Rally完成每个场景的测试是通过相应client调用openstack API操作。

以下举例分析场景create_and_list_networks函数。在执行函数之前会有一些validation装饰器。

1、validation.required_openstack

 验证scenario类型方法运行时对于用户角色（admin/user）的要求是否得到满足，如果要求admin用户执行task，则在装饰器参数中提供admin=True，如果要求普通用户身份执行，提供users=True，默认两个值都是False。使用此装饰器，上述两个参数至少提供一个为True。检验过程中会查询当前deployment的配置，是否提供scenario要求的用户角色。

2、validation.required_services

检验执行scenario类型方法测试时，要求的openstack service是否可用，使用装饰器时，要求在参数中提供待检验的Service名称，并且名称的书写必须包含在constants._Service所定义服务的范围内；此外，检验时，通过openstackclient查询services列表，待检查的服务应在services列表中；否则验证失败。

3、scenario.configure

         用于设置待测试方法的is_scenario和context属性，分别用于支持task的validate过程，以及通过在context中增加cleanup参数，实现测试后清理环境。

 

class NeutronNetworks(utils.NeutronScenario):     """Benchmark scenarios for Neutron.""" @validation.required_services(consts.Service.NEUTRON)     @validation.required_openstack(users=True)     @scenario.configure(context={"cleanup": ["neutron"]})       def create_and_list_networks(self, network_create_args=None):         """Create a network and then list all networks.           Measure the "neutron net-list" command performance.           If you have only 1 user in your context, you will         add 1 network on every iteration. So you will have more         and more networks and will be able to measure the         performance of the "neutron net-list" command depending on         the number of networks owned by users.           :param network_create_args: dict, POST /v2.0/networks request options         """         self._create_network(network_create_args or {})         self._list_networks()

 

参考文档：http://rally.readthedocs.io/en/latest/tutorial.html