SuccessBot 说

• Qiming：Senlin 已完成从 WADL 的 API 迁移。
• Mugsie：Kiall 修复了 gate – 开发现在可以继续了！！！
• notmyname：正好 6 年前今天，Swift 进入了生产环境
• kiall：DNS API 参考已上线 [1]。
• sdague：Nova 遗留 v2 api 代码已移除 [2]。
• HenryG：Neutron 中 oslo incubator 的最后残余部分已移除 [3]。
• dstanek：我能够使用新的 SAML2 中间件在 keystone 和 testshib.org 之间执行往返传输！
• Sdague：Nova 现在默认使用 Glance v2 进行镜像操作 [4]。
• Ajaeger：第一个项目特定安装指南已发布 – 祝贺 heat 团队！
• Jeblair：没有 Jenkins，只有 Zuul。
• 全部

为 OpenStack 项目要求公平竞争环境

• Thierry Carrez 提出了一项新的要求 [5]，适用于 OpenStack “官方”项目。
• 开放协作的基础重要特征是需要一个公平的竞争环境。不能给予任何特定组织不公平的优势。
  • 被指定为“官方”项目团队的项目需要以公平的方式运作。否则，它们本质上可能成为某个组织的特洛伊木马。
  • 如果在某个项目中，来自特定组织的开发人员受益于对特定知识或硬件的访问权限，那么该项目应根据“开放社区”规则被拒绝。
  • 像 Cinder 这样的项目提供了一个有趣的灰色地带，但只要所有驱动程序都在其中，并且有一个功能齐全（且流行）的开源实现，那么可能没有特定组织被认为是不公平地受益。
• 针对特定网络硬件的 Neutron 插件可能会给予硬件制造商的开发人员不公平的优势（可以访问硬件进行测试，并且能够查看和修改其专有源代码）。
• 不符合开放社区要求的开源项目仍然可以在生态系统中存在（使用 gerrit 和 openstack/* git 仓库进行开发，gate 测试，但作为非官方项目）。
• 完整线程

为互操作性测试添加禁用某些严格响应检查的选项

• Nova 引入了其 API 微版本变更 [6]
• QA 团队将严格的 API 模式检查添加到 Tempest，以确保没有额外的 Nova API 响应 [7][8]。
  • 在过去一年中，参与 OpenStack 授权商标计划的三家供应商受到了这方面的影响 [9]。
• DefCore 工作组确定了 OpenStack 授权计划的指南。
  • 包括来自 Tempest 的具有相关功能测试的功能。
  • 开发方向的未来与部署和用户采用的滞后指标之间存在平衡。
• 工作组的一名成员 Chris Hoge 想要实施一个临时弃用严格 API 检查要求的方案。
  • 虽然这在开发社区中公开讨论过，并且实施需要一些时间。但它仍然迅速落地，并在一夜之间破坏了几个现有的部署。
  • 由于通过的 TC 决议 [10] 建议 DefCore 使用 Tempest 作为功能测试的唯一来源，因此下游部署者无法使用没有这些严格响应检查的旧版本 Tempest。
• 提议
  • 短期
    • 将有一个蓝图和补丁到 Tempest，允许配置一个 Nova API 的灰名单，其中对附加属性的严格响应检查将被禁用。
    • 使用此代码将发出弃用警告。
    • 它将于 2017.01 移除。
    • 供应商需要提交带有附加响应数据的 API 灰名单，这些数据将发布到他们的市场条目中。
  • 长期
    • 预计供应商将与上游合作，更新返回附加数据的 API。
    • 在 2017.01 指南发布后，将不再允许该弃用。
• 前 QA PTL Matthew Treinish 认为这是一个巨大的倒退。
  • 已经实施了带外扩展或将额外内容注入响应的供应商认为，通过这样做他们是可互操作的。API 不是供应商差异化的场所。
  • 作为多个云的用户，响应中的随机数据使得编写代码更加困难。哪些是特定于供应商的响应？
• 不给供应商更多市场时间的替代方案
  • 让一些供应商不必要地退出 Powered 计划，从而削弱它。
  • 强制 DefCore 采用非上游测试，无论是作为分支还是独立的测试套件。
• 如果新的执行策略是通过向 Tempest 添加新测试来应用的，那么 DefCore 可以使用其流程在一段时间内添加它们，并且下游部署者可能不会遇到问题。
  • 而是对一堆现有测试的行为进行了更改。
• Tempest master 今天支持所有当前支持的稳定分支。
  • 在 git 仓库中创建标签以支持发布时，会添加/删除支持。
    • 无分支 Tempest 最初是在 Icehouse 发布中启动的，并且被实施以强制 API 在发布边界上相同。
• 如果 DefCore 想要 Kilo、Liberty 和 Mitaka 的最低公分母，那么有一个标签 [11]。对于 Juno、Kilo、Liberty，标签将是 [12]。
• 完整线程

没有 Jenkins，只有 Zuul

• 自 OpenStack 诞生以来，我们一直使用 Jenkins 来执行测试和构建工件。
  • 当我们只有两个 git 仓库时，我们有一个 Jenkins master 和几个 slave。这很容易维护。
  • 随着 1,200 个 git 仓库、8,000 个作业分布在 8 个 Jenkins master 和 800 个动态 slave 节点上，情况已经发生了重大变化。
• Jenkins job builder [13] 被创建来从模板化的 YAML 创建 8,000 个作业。
• Zuul [14] 被创建来推动项目自动化，指导我们的测试，每天运行数万个作业。响应于
  • 代码审查
  • 堆叠潜在的变更以进行测试。
• Zuul 版本 3 具有重大变更
  • 更容易在多节点环境中运行作业
  • 易于管理大量作业
  • 作业变体
  • 支持树内作业配置
  • 能够使用 Ansible 定义作业
• 虽然版本 3 仍在开发中，但它今天能够运行我们的所有作业。
• 截至 6 月 16 日，我们已关闭了最后一个 Jenkins master，并且我们的所有自动化都由 Zuul 运行。
  • Jenkins job builder 有 OpenStack 以外的贡献者，并且将继续由他们维护。
• 完整线程

语言与“OpenStack”的范围

• OpenStack 在哪里停止，更广泛的开源社区在哪里开始？两个选项
  • 如果 OpenStack 只是一个“集成引擎”，用于更低级别的技术（例如，hypervisor、数据库、块存储），则范围有限，Python 应该足够，我们不需要分散社区。
  • 如果 OpenStack 是“为了实现我们的使命而需要的一切”，那么我们需要添加一种语言来涵盖更低级别/本机优化。
• Swift PTL John Dickinson 提到，定义 OpenStack 项目的范围并不能定义实现它们所需的语言。这些考虑因素是正交的。
  • OpenStack 被定义为完成使命声明所需的一切。
  • 定义“较低级别”非常困难。由于 Nova API 正在监听公共网络接口并与集群中的各种服务协调，因此它是否足够低级别以考虑优化？
• 另一种方法是产品为中心。“较低级别的部分是 OpenStack 依赖项，而不是 OpenStack 本身。”
  • 不受 TC 管辖，并且可以使用任何被认为必要的语言和工具。
  • 有大量的开源项目和库，OpenStack 需要完成其使命，这些项目不是“OpenStack”：Python、MySQL、KVM、Ceph、OpenvSwitch。
• 我们是否想从事构建数据平面服务，这些服务将遇到 Python 的限制？
  • 控制平面服务不太可能遇到需要重写成另一种语言的扩展问题。
• Swift 首先在 Python 中遇到限制，因为该项目的成熟度，并且他们现在专注于这种优化。
  • Glance（部分数据平面）遇到了这个限制，并通过使用 Ceph 并将其直接暴露给 Nova 来缓解。因此，现在 Glance 只关心位置和元数据。像 Ceph 这样的依赖项关心数据平面。
• Go 编程语言的决议在之前的技术委员会会议上讨论过，但未通过 [14]。John Dickinson 和其他人计划为 Swift 提出一项使用该语言的例外方案。
• 完整线程