OpenStack中的Tempest

前言

开源有一个不好的地方就是发展变化太快，当然，对于一个健康的开源社区来说，这是好事。可是，没人能保证一个社区永远会健康的发展。对于OpenStack社区开说，最近的关于Nova API的讨论已经够多的了，感兴趣的读者可以参考这里、这里和这里。类似于这样的讨论对于社区本身可能好事，但对于那些想依托社区做一些事情的公司或企业来说，也许是场灾难。

好了，废话不说，这篇文章想讲的跟上面的牢骚其实没有多大关系，呵呵。

什么是Tempest

本文讲的是Tempest，把这个单词首字母大写的原因是Tempest是OpenStack社区的一个独立的项目。Tempest是随openstack开发的测试套件，能够对openstack各个service进行全面测试。其实，我眼里的测试分为几种：unit test, functional test(integrated test), end-to-end test, stress test, performance test，作为门槛，其实Tempest做的，仅仅是第二类，以及第三类的小部分。第一类是UT，包含在各个项目里面，新的代码提交是要求必须写UT的。而第四类和第五类，并不在Tempest的范畴，一个新兴的项目Rally可能会接管。当然，对于Tempest的介绍还有很多，如果有心的话，仔细阅读项目目录中的README和hacking文档后，对Tempest也就基本了解了。

Tempest的配置文件

其实写这篇文章的最初来源是，项目中想用Tempest作为健康检查工具的一部分，但Tempest的运行是有一些预置条件的，配置文件便是其中一个，想了解配置文件的生成，从而做一些定制化。Tempest中的用例在执行时，会从配置文件中获取当前环境的一些信息。然而，在时隔半年再翻开Tempest代码时，发现已经陌生了很多。所以，写下本篇，以备后用。

配置文件的生成

在Tempest的README文件中，有这么一段话：

Detailed configuration of tempest is beyond the scope of this document. The etc/tempest.conf.sample attempts to be a self documenting version of the configuration. The sample config file is auto generated using the script: tools/generate_sample.sh

配置文件可以自动生成，tools/generate_sample.sh脚本的内容也很简单：

#!/bin/sh
MODULEPATH=tempest.common.generate_sample_tempest tools/config/generate_sample.sh $@

OK，问题来了，不知道其他人怎么解释这句，反正我第一眼，还以为仅仅是一个环境变量的定义。但仔细一看，好像有点看不懂的样子。经过搜索和研究，该问题解答如下：

• PATH=/usr/bin:/bin command 临时改变环境变量，但并不改变command执行时的环境变量；
• PATH=/usr/bin:/bin 改变shell环境变量；
• env -i PATH=/bin command 临时改变环境变量，但并不改变command执行时的环境变量；
• env -i PATH=/bin 临时改变环境变量，并不改变以后shell执行时的环境变量；

简单解释，就是带着环境变量MODULEPATH执行generate_sample.sh，执行后，MODULEPATH就毫无意义了。也就是说，配置文件的生成任务，还是在generate_sample.sh脚本中。

我就不卖关子了，直接讲一下generate_sample.sh脚本中需要注意的东西：

• getopt的使用，可以参见我之前的博客
• shell中变量的定义，${var:-newstring}表示，如果var为空或未定义，返回newstring，否则返回原值；${var##string}表示，返回从var左边删除string后的字符串，贪婪匹配；
• find命令参数-path表示排除搜索路径；
• grep -l 表示匹配文件内容；
• sort -u 表示排序后去重；

注意事项

• 假如你自定义了些配置项，而且已经写了单独的conf.sample文件，想在tempest.conf.sample文件自动生成时合并进去，那么可以将你自己的sample文件放在tempest目录下的tools/config/中，文件名以conf.sample结尾
• Tempest会自动搜索tempest目录下（tests目录除外）的模块，如果某个模块中包含cfg.Opt类的变量，就会读取相应的配置项信息
• 如果你的自定义模块在其他地方，而且里面也有一些配置项定义，那么可以通过定义TEMPEST_CONFIG_GENERATOR_EXTRA_MODULES环境变量，罗列出自定义的模块，相关的配置项也会自动生成。

未来发展

• 提高并发性，当然，首先需要解决资源竞争的问题
• 对于每一套真实的环境，都要手工修改相关的配置项（至少要修改user ids, openstack endpoints, and basic flavors and images），不太智能。于是社区有了相关BP解决这个问题.