puppet-ceph update

loic

在去年年底，一个新的 puppet-ceph 模块 被启动，目标是重新统一数十个独立的努力。我对我们所取得的成就感到非常高兴。我们正在 取得进展，尽管 我们的社区比较分散，但更重要的是，我们做事的方式不同。

恕我直言（以及 puppet-ceph 的核心审查员 肯定会有不同的看法），这正是 puppet-ceph 特别之处所在

  • 严格的集成测试策略。

    我花在 puppet-ceph 上超过一半的时间都在思考如何使用和编写集成测试。虽然 puppet 世界很好地支持单元测试，但集成测试是新的。我们首先尝试了 rspec-system，但由于它被废弃，我们不得不对其进行分叉。我们还 编写并维护了一个工具 来运行这些测试，因为没有标准的从 gerrit 执行此操作的方法。经过几个月的观察（主要是检查它不会被废弃 ;-) 我们计划将 我们的测试 翻译到 beaker，使用 docker（模仿 elasticsearch 示例说明）。主要原因是依赖过时的工具不可持续。次要原因是基于 vagrant 的测试需要专用的硬件（今天我们重新安装了由法国自由软件基金会和 tetaneutral.net 慷慨地托管的机器），而 docker 可以使用一个 OpenStack 虚拟机，其根文件系统由 Ceph 支持，并且 /var/lib/docker 位于连接到同一硬件的 LVM 卷上 以提高 I/O 效率。

  • 利用 OpenStack 开发工作流程。

    所有 更改都提交到 gerrit，并且在合并到 master 之前，必须由两名核心审查员审查。然后，它才会镜像到 Ceph 命名空间中的仓库（https://github.com/ceph/puppet-ceph/）。这种策略适合大型项目，但对小型项目施加了很长的延迟，因为核心审查员的可用性较低。David Gurtner 最近加入了核心审查员团队，这有很大帮助，但大多数更改的阻塞因素仍然是审查员的可用性。虽然通过放宽规则，允许一名审查员批准更改来解决这个问题很诱人，但副作用是较少的核心审查员会了解代码。目前，项目的节奏或多或少与每个核心审查员的理解同步。如果我们试图加快速度，我们中的一些人会迷失方向。

  • 善于与兼职开发者合作。

    没有核心审查员是由其雇主任命来从事 puppet-ceph 的工作。我可能无法甚至查看一个池请求数周，因为我的工作需要我全部的注意力。当我回到 puppet-ceph 时，我会获取最新的更改，在本地运行集成测试，并在它们运行时阅读它们。这告诉我自从我离开后发生了什么。不是代码可能有效或无效的术语，而是代码证明它按预期工作的方式的术语。在一个小时内，我就可以回到项目中并做出贡献。当然，我失去了我的感觉，并且会犯愚蠢的错误：大多数都是由集成测试和最终由其他核心审查员捕获的。这是一种在许多自由软件项目中常见的开发模式，它在让我乐于回到它们的事实上起着重要作用。如果没有集成测试，开发人员要么非常专注并且始终 100% 专注于项目，要么不断面临反复回归的挫败感。

  • 缓慢而稳定

    存在许多 puppet ceph 模块，其中大多数都存在活动爆发，具体取决于谁需要什么。它们比 puppet-ceph 运行得更快。但是，所有这些模块，毫无例外，都受到持续回归的困扰，因为它们没有集成测试。最后一次提交的作者可能只是手动测试了一个没有跟踪的使用案例。试图弄清楚它的人毫无线索。puppet-ceph 做的事情很少，但不会发生回归。它在 Centos 和 Ubuntu 上进行了测试，用于 Ceph 发布版本 Dumpling、Emperor 和 Firefly。如果我要使用与集成测试中我所能读到的类似的使用案例来部署 puppet-ceph，我会确信它有效。它们既是示例，也是证明它有效的证据。

    还有一些其他我喜欢的 puppet-ceph 的方面，尽管它们不那么突出。它是一个真正的自由软件新贡献者的训练场：数十人做出了他们的第一次贡献，并学习了 puppet-ceph 中的工具和社交动态。它有时具有挑战性和嘈杂，但也令人耳目一新，我希望在未来几年，这些学生将成为自由软件社区的杰出公民。它支持多种使用模式（以通常的方式编写清单，基于场景的部署，纯 hiera），其中一些是我在它们被引入时发现的。

最后但并非最不重要的一点是，尽管在尝试开辟新道路时会遇到困难，但每个人都非常乐于合作和迁就。从事 puppet-ceph 的工作是一种乐趣，我希望能够尽可能长时间地继续 :-)