本文介绍如何搭建一个运行在OpenStack持续集成平台上的测试平台。在开始之前，最好详细了解一下本文上游OpenStackCI平台的一些背景知识。阅读本文后，您将掌握构建测试台所需的所有背景知识。什么是测试平台？简单来说，就是运行第三方独立测试——通过将第三方驱动或硬件配置到OpenStack环境中——然后在codereview过程中展示相关的测试报告。通过这种实时代码审查反馈，很容易控制代码质量。下图中，你会看到Neutron外测平台添加的numberVerified+1和一个Verified-1标签：测试平台引入的Verified+1和-1标签每增加一个新标签，就会有一条评论生成后，点击评论会链接到测试平台的相关测试：评论对应测试平台的一条评论。开发者可访问相应链接，排查导致测试平台失败的相关补丁问题。为什么需要外部测试平台？好处如下：得到及时的反馈提早提交相关补丁后，测试平台可以发现可能出现的故障，缩短问题解决时间。减少对真实测试环境的依赖。为了让开发者有更多的时间专注于业务代码的质量，不断提高质量标准，通过相关用例测试部分或全部驱动API，确保与OpenStack的兼容。如果你和OpenStack开发者聊天，你就会知道，当他们面临如何选择存储或网络供应商或后台管理模型来兼容要部署的OpenStack的问题时，这个优势将是多么的明显！何必费心思考如何选择测试平台呢？许多OpenStack项目和供应商已经讨论了将测试平台集成到上游OpenStack持续集成平台中的必要性。Neutron开发社区已经领先于游戏，大约有十几家供应商已经在Neutron代码审查中包含测试链接。Cinder项目正在讨论在提交代码后立即实施测试驱动的正确性策略。同样，Nova社区也讨论了讨论监控源代码仓库的相关策略。或许这对于一些团队来说并不是什么新鲜事，希望本文能为新的OpenStack供应商更快地集成提供帮助。所需工具可配合OpenStack持续集成平台的测试平台组件如下：JenkinsCI运行相关项目测试任务的服务器Zuul组织运行Jenkins任务机制的系统JenkinsJobBuilder(JJB)简化创建和维护Jenkins任务配置文件Devstack-Gate和Nodepool脚本从源代码库构建OpenStack环境的脚本。下面我将介绍如何使用脚本和Puppet来实现上述测试平台的组件功能。当然，还有其他方法可以实现同样的功能。您可以根据文档手动安装相关组件。但我不推荐这个。手动安装有利也有弊：一旦出现问题，所有工作都需要返工。如果之前进行了任何配置更改，现在将完全从内存中恢复。不可能轻易创建一个新的测试平台示例。如果你想实现它，你必须重新配置它。最好的方式是使用配置管理平台，如Puppet、Chef、Ansible或SaltStack来管理组件的部署，使用Git来管理配置库。本文将通过Bash脚本和Puppet模块在多台主机或虚拟机上搭建一个测试平台。相关代码在GitHub源码库中。如果你不想用Puppet或者想用其他工具，也没问题。你也可以从刚才的源代码仓库中得到很多启发（我会在以后的脚本中写一些OpenStack的外部测试项目）。开始安装前需要注意的几件事：按照以下步骤进行操作应该没问题。获取上游服务账号为了能够向openstack.org发布测试平台评论意见，需要先在OpenStackInfra团队注册一个账号。详情如下这个链接的说明总之，你需要发送一封邮件到OpenStackInfra邮件列表，其中包含以下内容说明：作为系统帐户的电子邮件地址（必须是唯一的Gerrit帐户）帐户名缩写将是在代码审查中显示（可选）帐户详细描述（可选但推荐）联系信息（IRC句柄、电子邮件地址或其他间接联系电子邮件）方便上游基础团队联系和访问Gerrit的SSH键值组公钥。注意不要在SSH中添加新的代码行。Gerrit服务账号没有SSH键值组？你可以创建一个：ssh-keygen-trsa-b1024-N''-fgerrit_key上面的命令会生成一个兼职组：一个名为gerrit_key和gerrit_key.pub的文件。通过电子邮件将gerrit_key.pub的内容发送到OpenStackInfra邮件列表。保留以上两样东西以备后用。在创建Git配置仓库并开始安装测试平台后，Puppet模块会保存一系列系统配置文件，包括Gerrit服务账号的SSH私钥。保存这些文件的理想方式是Git配置存储库，任何更改都会像保存源代码一样被保存。我在GitHub上开了一个账号源码仓库作为例子。与以往不同，我推荐使用gitclone代码到本地库，而不是使用fork模式：gitclonegit@github.com:jaypipes/os-ext-testing-data~/mydatarepocdmydatareporm-rf.gitgitinit.gitadd.gitcommit-a-m"Mynewdatarepository"现在你有了一个本地配置库来保存相关的配置文件，不管你把它放在哪里问题——可能是GitHub，甚至是其他地方的Git服务器。将Gerrit服务账号的私钥放入数据仓库现在需要将上一步创建的key-value组放入仓库中访问Gerri服务账号。如果使用ssh-keygen命令新建key-value组，还需要将gerrit_key文件复制到仓库中。如果你既没有创建新的键值组（原来使用的那个）或者名称不是gerrit_key，那么复制文件到仓库，打开vars.sh，修改如下代码：exportUPSTREAM_GERRIT_SSH_KEY_PATH=gerrit_key把gerrit_key改成相应的SSH私有Spoon名称。设置Gerrit账户用户名打开库中的filevars.sh（假设你还没有打开），修改如下代码：exportUPSTREAM_GERRIT_USER=jaypipes-testing将jaypipes-testing改为你的Gerrit账户名。在TestJenkinsJobOpenetc/jenkins_jobs/config/projects.yaml上设置供应商名称。修改如下代码：vendor:myvendor将myvendor改为对应的组织名称（可选）在数据仓库中创建JenkinsSSH键值对。有公/私SSH键值对（叫jenkins_key[.pub]。因为私钥以前放过，现在其实没用了，举个例子。如果你想建立一个新的，这样做：cd$DATA_DIRECTORYssh-keygen-trsa-b1024-N''-fjenkins_keygitcommit-a-m"Changedjenkinskeytoanewprivateone"保存更新数据仓库，至此数据仓库的配置已经处理完毕，接下来就可以开始安装Jenkins主服务器了。但是记得保存相关的修改，放到配置仓库中：gitadd.gitcommit-a-m"AddedGerritSSHkeyandusername"gitpushserverrequirements在服务器（主机，虚拟机）上安装Jenkins主从之前，或者LXC容器），检查以下条件：相关包已经安装：wgetopensslssl-certca-certificates配置在~/.ssh/GitHub需要的SSH值。这也会影响~/.ssh/known_hosts和~/.ssh/configfiles文件。设置JenkinsMaster端，在需要安装JenkinsMaster端的虚拟机（或LXC容器）上执行如下操作：gitclone$YOUR_DATA_REPOdatawgethttps://raw.github.com/jaypipes/os-ext-testing/master/puppet/install_master.shbashinstall_master.sh上面的代码创建SSL自签名证书使Apache能够运行JenkinsUI，然后安装Jenkins、JenkinsJobBuilder、Zuul、Nodepool脚本和其他相应的包文件。注：写这篇文章的时候，Zuul系统已经重构了一点重构，所有Zuulgit相关的任务都由一个叫做zuul-merger的进程管理。我已经更新了存储库的os-ext-testing部分，如果你在2014年2月18日之前从Puppet模块安装了Jenkinsmaster和Zuul，你需要在master端执行以下操作来重新配置：#注意：这只是如果您在2014年2月18日星期二之前从#os-ext-testing存储库安装了Jenkinsmaster，则必须这样做！sudoservicezuulstopsudorm-rf/var/log/zuul/*/var/run/zuul/*sudo-i#作为root...cd/root/config;gitpull/root/configexitcdos-ext-testing;混帐拉；cd../cpos-ext-testing/puppet/install_master.sh.bashinstall_master.shPuppet运行完成后访问http://$HOST_IP:8080打开Jenkins界面。启用Zuul的Gearmanworker以与Jenkins交互：单击左侧链接“ManageJenkins”，单击“ConfigureSystem”，链接将下拉至“GearmanPluginConfig”。勾选“EnableGearman”点击“TestConnection”按钮，确认Jenkins已连接到Gearman在页面底部下拉到`Save`注意：DarraghO'Reilly第一次提到Gearman插件不可用安装在他的机器上（尽管它已经安装）。这时只需要重启Jenkins服务即可解决问题，然后在ManageJenkins->Configure页面配置启用GearmanPlugin。完成以上操作后，启动Jenkins任务，启动Zuul：sudojenkins-jobs--flush-cacheupdate/etc/jenkins_jobs/config/sudoservicezuulstartsudoservicezuul-mergerstart刷新Jenkins界面后，两个相关任务出现：JenkinsMaster界面显示Sandbox任务是由JJB创建的。恭喜你成功部署了Jenkinsmaster。现在使用sandbox-noop-check-communication任务来测试测试平台与上游之间的通信。默认情况下，我将任务配置为执行openstack-dev/sandbox项目[1]。这是配置库中的相关配置etc/jenkins_jobs/config/projects.yaml文件：-project:name:sandboxgithub-org:openstack-devnode:masterjobs:-noop-check-communication-dsvm-tempest-full:node:devstack_slave默认端是master。sandbox-dsvm-tempest-full运行在devstack_slave上，后面会详细介绍。Zuul配置中有两条管道：check和gate。下面只有一个openstack-dev/sandbox的简单项目layout.yaml：projects:-name:openstack-dev/sandboxcheck:-sandbox-noop-check-communication默认只有sandbox-noop-check-communication任务运行，并且给openstack-dev/sandbox项目打了新补丁，或者提交了包含“rechecknobug”或者“recheckbugXXXXX”字样的评论的情况下触发。让我们构建一个项目补丁，看看sandbox-noop-check-communication任务是否正确执行。操作前，tailZuuldebuglog，过滤掉“sandbox”。这样可以更方便地查看通信任务的进度：sudotail-f/var/log/zuul/debug.log|grepsandbox创建一个沙箱补丁。请注意，它正在创建区域而不是Jenkins：gitclonegit@github.com:openstack-dev/sandbox/tmp/sandboxcd/tmp/sandboxgitcheckout-btesting-exttouchmytestgitaddmytestgitcommit-a-m“Testingcomms”gitreview输出：jaypipes@cranky:~$gitclonegit@github。com:openstack-dev/sandbox/tmp/sandboxCloninginto'/tmp/sandbox'...remote:Reusingexistingpack:13,done.remote:Total13(delta0),reused0(delta0)Receivingobjects:100%(13/13),done.Resolvingdeltas:100%(4/4),done.Checkingconnectivity...donejaypipes@cranky:~$cd/tmp/sandboxjaypipes@cranky:/tmp/sandbox$gitcheckout-btesting-extSwitchedtoanewbranch'testing-ext'jaypipes@cranky:/tmp/sandbox$touchmytestjaypipes@cranky:/tmp/sandbox$gitaddmytestjaypipes@cranky:/tmp/sandbox$gitcommit-a-m"Testingcomms"[testing-ext51f90e3]Testingcomms1filechanged,0insertions(+),0deletions(-)createmode100644mytestjaypipes@cranky:/tmp/sandbox$gitreview:NewChanges:remote:https://review.openstack.org/73631remote:Tossh://jaypipes@review.openstack.org:29418/openstack-dev/sandbox.git*[newbranch]HEAD->refs/publish/master/testing-ext关注Zuul的调试日志。如果没有问题，应该会看到如下内容：2014-02-1416:08:51,437INFOzuul.Gerrit:Updatinginformationfor73631,12014-02-1416:08:51,629DEBUGzuul.Gerrit:Changestatus:NEW2014-02-1416:08：51,630Debugzuul.scheduler：AddingTriggerevent：2014-02-1416：08：51,630Debugzuul.scheduler：Doneaddingtriggerevent：2014-02-1416：08：51,630Debugzuul-14：51,630debugzuul-1nemering.48：：08：51,631DEBUGzuul.Scheduler：Processingtriggerevent2014-02-1416:08:51,631DEBUGzuul.IndependentPipelineManager:Startingqueueprocessor:check2014-02-1416:08:51,631DEBUGzuul.IndependentPipelineManager:Finishedqueueprocessor:check(changed:False)2014-02-1416:08:51,631DEBUGzuul.DependentPipelineManager4:DependentPipelineManager4-02-1416:08:51,631DEBUGzuul.DependentPipelineManager:Finishedqueueprocessor:gate(changed:False)如果看Gerrit的评论链接（运行gitreview后的结果链接），会有+1Verifiedvote:Thecommunicationissuccessful！好了，现在我们已经实现了一个全流程的外部测试平台，从Gerrit获取更新事件后触发持续集成服务器执行相关任务，然后将任务结果返回给Gerrit系统。下篇文章会讲到如何添加Jenkins子系统下一篇文章会在你的系统中添加一个Jenkinsslave，以实现基于devstack的gatetesting。如果您在实现过程中对本文或脚本有任何建议，请告诉我们！OpenStackSandbox项目用于测试外部测试平台和上游任务的集成。一旦提交了新的补丁，就会自动触发文中设置的Jenkins任务。
