通过 Spider 探讨“核心”话题

 

2013年8月23日

“核心”一词对于参与 OpenStack 社区的人们来说，具有广泛的含义和内涵。通过持续的讨论，我们发现不同受众的目标并不一定相同——事实上，在某些情况下，它们甚至是相互对立的！

我们最初开始完善“核心”的定义，是通过一项名为 IncUp 的工作。IncUp 是 TC 和董事会成员的共同努力，旨在改进孵化流程。这项工作也帮助我们认识到定义“核心”的复杂性。这种复杂性源于“核心”对 OpenStack 用户和贡献者，以及整个生态系统产生的不同影响。

解决问题
应董事会委托，Rob Hirschfeld 和我开始会面，以进一步推进定义“核心”的进程。这个过程的第一步是检查和定义每个受众的目标，Rob 在一系列博客文章[1]中详细介绍了我们所经历的思考过程。

在我们开始这个过程后不久，我们很快意识到这些不同受众的目标要么一致，要么存在冲突。我们使用不同的颜色在白板上绘制目标和冲突，创建了一个巨大的多色“蜘蛛”图，更像是一张思维导图。因此，我们目前将这项工作称为“蜘蛛讨论”，或者简称 spider。

问题陈述/目标
从最高层面来看，这项 spider 工作旨在推进 OpenStack 的使命，即打造无处不在的开源云计算平台。这个过程中的关键工作包括定义保护品牌、为用户提供良好体验以及加强协作社区所需的组件、流程和标准。OpenStack 标识是基金会定义和捍卫这些关键要素的工具。
为了使 OpenStack 实现者能够使用 OpenStack 标识，董事会受命提供具体且可验证的标准。然而，目前还没有可用的形式。因此，我们关于“什么是核心”的讨论和努力旨在确定这些标准。
立场声明
Spider 专注于将“核心”的标准分解为可引用的立场声明。这些声明将作为决策的基础，以便我们能够保持决策（以及最终实施）的渐进性。目前有 10 个正在演变的立场声明：1. 能够使用 OpenStack 商标 (OpenStack™) 的实现是核心。
1. 这是“核心”的法律定义，也是它对社区的重要性所在。

  1. 我们希望确保 OpenStack™ 标识具有意义。
  2. OpenStack™ 标识与 OpenStack 品牌并不相同；相反，董事会使用其对标识的控制权作为代理，以帮助管理品牌。

2. 核心是整个项目的一个子集

  1. OpenStack 项目旨在成为一个广泛而多元化的社区，不断有新项目进入孵化，不断有新的实现被添加。这种创新对 OpenStack 至关重要，但与“核心”的定义是分开的。
  2. 基金会可能会单独管理其他标识，并根据董事会的决定提供给平台生态系统。
  3. “OpenStack API 兼容”标识不属于本次讨论范围，不应被假定。
3. 核心定义可以平等地应用于所有使用模式

  1. 无论运营商（公共、私有、社区等）如何，不应存在多个 OpenStack 定义。
  2. 虽然预计每个部署都是相同的，但差异必须是可量化的。

4. 声明 OpenStack 需要使用指定代码框架

  1. 声称使用 OpenStack™ 标识的实现必须使用批准的 API 框架代码。
  2. 仅通过所有测试但未使用 API 框架的实体将不被视为 OpenStack 的一部分或获得批准。这可以防止实体在加入社区之前使用 API，并向更大的社区揭示替代实现中的位腐烂。
  3. 通过实施此要求，互操作性得到了极大的提高，因为实现之间有更多的共享代码。

5. 项目必须具有开放的参考实现

  1. OpenStack 将需要为所有项目提供开源参考基础插件实现（如果不是 OpenStack 的一部分，参考插件的许可模式必须兼容）。
  2. 我们定义插件为具有通用 API 框架的替代后端实现，使用通用 _代码_ 来实现 API。
  3. 这确立了项目（在技术上可行的情况下）将实施插件或扩展架构的期望。
  4. 这已经应用于几个项目，并解决了生态系统支持，进一步促进了创新。
  5. 参考插件按定义是完整的capability集合。参考插件中没有功能不可用的情况是可以接受的。
  6. 这将使替代实现能够提供创新或差异化的功能，而无需强制更改参考插件实现。
  7. 这将使参考能够扩展，而无需强制其他替代实现匹配所有功能并重新认证。

6. 供应商可以替代替代实现

  1. 如果供应商插件通过所有相关测试，则可以将其视为参考插件的完整替代品。
  2. 如果供应商插件未通过所有相关测试，则要求供应商在实现中包含开源参考。
  3. 替代实现可以传递任何有意义的测试，并应添加测试以验证新功能。
  4. 他们还需要拥有所有必须通过的测试（参见 #10）才能声称使用 OpenStack 标识。

7. OpenStack 实现由开放社区测试验证

  1. 供应商的 OpenStack 实现必须达到 100% 的必须覆盖率。
  2. 已实施的测试可以标记为必须具备的列表。
  3. 认证者需要披露他们的测试差距。
  4. 这将给 Tempest 项目带来很大的压力。
  5. 测试套件的维护将成为基金会的核心责任，可能需要额外的资源。
  6. 实现和产品可以根据兼容性的发布而有所不同。
  7. 消费者必须有一种方法来确定系统与参考的区别（发布、发现等）。
  8. 测试必须以适当的方式响应 BOTH 通过和失败（错误的返回会拒绝整个套件）。

8. 测试可以远程或自助管理

  1. 插件认证由 Tempest 自认证模型驱动。
  2. 自认证者需要发布他们的结果。
  3. 自认证者还需要发布足够的信息，以便第三方能够构建参考实现以通过测试。
  4. 自认证者必须包含已认证的操作系统。
  5. 希望自认证实现参考 OpenStack 参考架构“风格”而不是定义自己的参考（需要一种发布和同意风格的方式）。
  6. 基金会需要定义争议解决机制（即信任但验证模型）。
  7. 所有生态系统合作伙伴都需要做出“适用于 OpenStack”的声明，并且该声明是可支持的。
  8. 如果 API 消费者对任何通过所有“必须通过”测试的实现有效，则可以声称正在使用 OpenStack API。
  9. API 消费者可以声明他们正在使用 OpenStack API，并有一些“可能具备”的项目作为要求。
  10. API 消费者预计会编写测试来验证他们的所需行为（作为“可能具备”测试提交）。

9. 基金会选择一部分测试作为“必须通过”

  1. OpenStack 机构将建议将哪些测试从“可能具备”提升到“必须通过”。
  2. “必须通过”测试的选择应尽可能基于可量化的信息。
  3. 必须通过的测试应从现有的可能通过的测试中选择。这鼓励人们为他们希望支持的案例编写测试。
  4. 我们将有一个过程，通过该过程将测试从“可能”列表提升到“必须”列表。
  5. 基本上，希望用户委员会提名将提升到董事会的测试。

10. OpenStack 核心意味着通过所有“必须通过”测试

  1. OpenStack 董事会拥有定义核心的责任（批准“必须”）。
  2. 我们不是在 Spider 工作中定义列表中包含哪些项目；而只是表明我们将如何定义核心。
  3. 可能具备的测试包括集成发布中的项目，但这些项目不是核心。
  4. 必须具备的项目必须符合 IncUp 委员会的结果定义的核心标准。
  5. 处于孵化或孵化前阶段的项目不应包含在“可能”列表中。

为了快速了解这些立场声明如何相互关联，Rob 在他的博客系列中发布了一个“OpenStack 核心流程图”。[2]

帮助我们最终确定这 10 个

这些立场声明是一项持续进行的工作。我们的目标是在 11 月董事会会议和香港峰会上最终确定它们。然而，为了实现这一目标，我们需要您的帮助，因此我们很乐意听取您的意见。我鼓励大家在 IRC 上与 Rob、我和任何董事会成员进行交谈，或者直接将您的反馈发布到基金会邮件列表。我们期待您的帮助，以实现基金会使命的目标！

Alan Clark
OpenStack 董事会主席

[1] http://robhirschfeld.com/2013/07/23/introducing-the-openstack-spider-graph-untangling-our-web-of-interdependencies/
[2] http://robhirschfeld.com/2013/08/07/visualizing-the-openstack-core/

发表评论

您的电子邮件地址将不会被公开。 必填字段已标记 *