扩大 Ceph 社区实验室规模

loic

Ceph 集成测试至关重要且成本高昂。与可以在笔记本电脑上运行的单元测试不同，它们需要多台机器来部署实际的 Ceph 集群。随着 Ceph 开发人员社区的扩大，社区实验室需要扩大规模。

当前开发流程及其挑战

当开发人员为 Ceph 贡献代码时，流程如下

  • 开发人员提交一个 拉取请求
  • 在审查者对拉取请求满意后，它会被安排进行集成测试（通过添加 needs-qa 标签）
  • 测试人员将拉取请求合并到集成分支中，与其他 needs-qa 的拉取请求一起，并设置一个标签来告知 (s)he 已经这样做（例如，如果 Kefu Chai 这样做，他会设置 wip-kefu-testing 标签）
  • 测试人员等待 为集成分支构建软件包
  • 测试人员在社区实验室中安排一系列 集成测试
  • 当套件完成后，测试人员分析集成测试结果，找到负责失败的拉取请求（当集成分支中的拉取请求数量超过几个时，这可能具有挑战性）
  • 对于每个失败，测试人员都会向有缺陷的拉取请求添加评论，并附上指向集成测试日志的链接，礼貌地要求开发人员解决该问题
  • 当集成测试通过时，测试人员会合并拉取请求

随着 Ceph 的贡献者数量增加，运行集成测试和分析其结果成为瓶颈，因为

  • 获取集成测试结果通常需要几天时间
  • 只有具有社区实验室访问权限的人才能运行集成测试
  • 分析测试结果耗时

增加社区实验室中的机器数量将加快集成测试的速度。但获取硬件、托管和监控它不仅需要几个月的时间，还需要大量的系统管理工作。Ceph 开发人员社区的增长速度快于社区实验室。而且，为了使事情更加复杂，随着 Ceph 的发展，集成测试的数量增加，需要更多的资源。

当开发人员频繁为 Ceph 贡献代码时，(s)he 会获得访问 VPN 的权限，这允许她/他安排集成测试。例如，Abhishek Lekshmanan 和 Nathan Cutler 现在可以自行运行和分析回端口的集成测试，他们可以访问社区实验室并这样做。但获得 VPN 访问权限的过程需要几周时间，并且正确使用它的学习曲线很大。

虽然这对于社区实验室用户来说大多是不可见的，但保持其运行的系统管理工作量很大。Dan Mick、Zack Cerza 和其他人每天都在修复问题。随着社区实验室规模的扩大，这项工作量增加，需要难以获得的技能。

通过公共 OpenStack 云简化工作流程

截至 2015 年 7 月，在公共 OpenStack 云上运行集成测试成为可能。更重要的是，新开发人员注册和安排集成测试不到一个小时。可以利用这个新设施来简化工作流程，如下所示

  • 开发人员提交一个 拉取请求
  • 开发人员需要附上成功的集成测试运行结果，以证明该功能或错误修复
  • 在审查者对拉取请求满意后，它会被合并。

不再需要 测试人员，因为开发人员现在有能力运行集成测试并解释结果。

测试结果的解释更简单，因为每次运行只有一个拉取请求。开发人员可以将她的/他的运行与社区实验室的最新运行进行比较，以验证未修改的代码通过。 (s)he 还可以以 交互模式调试失败的测试。

与社区实验室不同，测试集群的生命周期很短，不需要系统管理技能。它是在云中按需创建的，并且可以在分析完结果后立即销毁。

安排和解释集成测试的学习曲线降低。开发人员需要了解 teuthology-openstack 命令以及如何解释测试失败。但 (s)he 不需要其他 teuthology-* 命令，也不需要获得社区实验室的 VPN 访问权限。