DefCore 为 OpenStack 带来定义

名字代表什么？ 实际上，代表很多。为了确保共享相同名称的产品之间的兼容性，用户可以期望核心功能集在不同的发行版中保持一致，这一点非常重要。对于像 OpenStack 这样由许多相互关联的组件组成的大型项目来说尤其如此。

Rob Hirschfeld 正在努力解决这个问题。他担任 OpenStack DefCore 委员会的联合主席，该委员会正在领导为 OpenStack 创建明确定义的努力，通过定义所有 OpenStack 产品的能力、代码和必须通过的测试。Hirschfeld 还在 OpenStack 基金会董事会中担任民选社区职位之一，并且是戴尔的杰出云架构师，他在那里从事大规模集成云系统的工作。

我请 Hirschfeld 分享一些关于 OpenStack、DefCore 工作以及他在 OSCON 即将发表的演讲 的信息，在这次采访中。

在不透露太多信息的情况下，您将在 OSCON 上讨论什么？是什么驱动了对 DefCore 的需求？

我将通过实际案例向用户和运营商介绍 OpenStack DefCore 流程的影响。我将讨论该流程如何运作，以及我们希望它如何改善 OpenStack 用户的生活。我们的目标是朝着云之间的互操作性迈进。

DefCore 的出现是为了回答围绕 OpenStack 的棘手且高风险的问题。诸如“Swift 是必需的吗？”以及“我必须交付 OpenStack 的哪些部分？”之类的问题对 OpenStack 生态系统具有非常重要的意义。

查看 OSCON 演讲者访谈的完整合集

在常规董事会会议上不可能就这些问题达成共识，因此 DefCore 退后一步，回归基本原则。我们一直在建立一个流程，帮助我们以透明的方式做出决策。这在开源社区中非常重要，因为贡献者和用户都希望有参与的基本规则。

关于 DefCore 是什么以及不是什么，OpenStack 邮件列表上似乎有很多讨论。您的定义是什么？

首先，DefCore 仅适用于 OpenStack 名称的商业用途。集成代码库和社区活动有不同的规则。这是最容易混淆的地方。

基本上，DefCore 确立了 OpenStack 产品所需的最低功能集。

更长的版本包括它是一个由董事会管理的流程，旨在非常透明和客观。长期目标是确保 OpenStack 云以可衡量的方式实现互操作性，并且我们也鼓励我们的供应商生态系统继续参与上游开发和测试的创建。

DefCore 的最后一个重要组成部分是我们正在捍卫 OpenStack 品牌。虽然我们希望拥有一个充满活力的供应商生态系统，但我们首先必须拥有一个了解 OpenStack 是什么并相信使用我们品牌的公司遵守有意义的基线的社区。

是否有其他开源项目使用“指定部分”的代码来定义他们的产品，或者这个概念是 OpenStack 独有的？您认为可以从其他项目对必须包含的内容以保留项目名称的使用的控制（或缺乏控制）中学到什么教训？

我不知道其他项目使用这些确切的词语。我们选择了“指定部分”，因为社区认为“插件”和“模块”太有限且太通用。我认为这个术语可能会令人困惑，但这是我们找到的最好的。

如果您将指定部分视为插件或模块，那么还有其他项目具有类似的概念。许多成功的开源项目（Eclipse、Linux、Samba）在功能上都是框架，具有非常强大的可扩展性。这些项目鼓励人们创造性地使用他们的代码库，然后以代码贡献的形式回馈他们学到的一些（并非全部）经验。如果返回上游的范围太广，那么回馈可能会变得繁琐，并导致分叉。

所有项目都必须努力在协作领域（加入社区需要开销）和独立模块（允许小型团队快速行动）之间找到适当的平衡。从这个角度来看，我认为这个概念与良好的工程设计原则非常一致。

关键目标是帮助技术和供应商社区了解在哪里可以安全地提供替代方案，以及在哪里他们应该在上游工作。在我看来，指定部分促进了创新，因为它们允许人们尝试新想法并针对特定的用例，而无需争论哪些部分被上游化。

作为社区选举产生的 OpenStack 董事会成员是什么感觉？您希望服务的利益是否与公司董事会席位不同，或者这种区别在实践中甚至不明显？

这就像试图在三级激流中划龙舟。有很多人在水中划桨，但我们既没有一起划桨，也无法与激流抗衡。我确实认为社区成员代表的利益与赞助席位不同，但我也认为 TC/董事会席位也不同。每位董事会成员都根据他们的经验和兴趣带来独特的视角。虽然这些观点受其雇佣关系的影响，但我很高兴地说，我没有看到他们的公司关系是其行为或决策的一个因素。我可以想到具体的案例，我看到相反的情况：董事会成员的行为超出了其公司关系。

当您回顾 OpenStack 在过去四年中的成长和发展历程时，您最大的惊喜是什么？

老实说，我对我们不得不重新发明这么多轮子感到惊讶。我不知道这是否是文化原因，还是确实是项目规模和范围造成的必要性，但似乎我们不得不（重新）创建我们本可以利用的东西。

您对 OpenStack 的 “K” 版本最兴奋的是什么？

添加平台服务，如数据库即服务、DNS 即服务、防火墙即服务。我认为这些 IaaS “邻近”服务对于完成云基础设施的故事至关重要。

有什么最后的想法吗？

在 DefCore 中，我们行动缓慢而谨慎，以确保人们有机会参与。我们还将一些问题推迟到未来，以便我们首先解决中心问题。我们需要社区发声（赞成或反对），以便我们能够加速：沉默意味着我们必须暂停以获取更多输入。

查看 OSCON 演讲者访谈的完整合集。