OpenStack 开发人员邮件列表摘要 1 月 23 日 – 2 月 5 日

2016 年 2 月 5 日

SuccessBot 说

目前存在一个问题，即我们应该在标头中使用服务类型还是项目名称。一些涉及此问题的评审 [7][8][9][10]。
我们应该选择更能服务于 API 消费者的内容，根据 Dean Troyer 的说法，API 工作组正在朝着正确的方向前进。
服务类型作为端点和 API 服务的首要标识符已得到确立，并且服务目录一直以来都是如此，并将始终如此。因此，服务类型应该是首选。
完整讨论串：http://lists.openstack.org/pipermail/openstack-dev/2016-January/085145.html

Gyorgy 宣布了一个新的 OpenStack 安装程序，使用 Ansible，基于 GPLv3 许可，但无需容器。
- 由于我们已经有了 OpenStack Ansible 项目和 Kolla，为什么还需要另一个安装程序
  - 容器增加了不必要的复杂性。
  - 软件包：避免混合使用 pip 和发行版软件包。发行版软件包包括诸如 init 脚本、正确的系统用户、升级可能性等。
    - Kevin Carter 提到，这些好处实际上也包含在 OpenStack Ansible 项目中。
如果没有容器，升级单个控制器可能会很棘手且具有破坏性，因为您必须同时升级每个服务。回滚也更容易。
OpenStack Ansible 项目今天就可以使用 is_metal=true 变量进行无容器部署。
完整讨论串：http://lists.openstack.org/pipermail/openstack-dev/2016-January/084963.html

重点
- 距离本周期非客户端库的最终发布还有 2 周时间。
- 距离客户端库的最终发布还有 3 周时间。
- 项目应专注于完成所有库中的功能工作。
发布操作
- 发布团队将在 3 周后的 M3 之前严格执行库发布冻结。
重要日期
- 非客户端库的最终发布：2 月 24 日
- 客户端库的最终发布：3 月 2 日
- Mitaka 3：2 月 29 日至 3 月 4 日（包括功能冻结和软字符串冻结）
完整讨论串：http://lists.openstack.org/pipermail/openstack-dev/2016-February/085705.html

在 OpenStack 有名字之前，就创建了“四个开放”原则，以定义我们作为社区的运作方式。
2010 年 OpenStack 启动时，它与其他开源云平台（Eucalyptus）不同，后者遵循开源核心策略，发布一个残缺的社区版本和一个“企业版”。
今天我们有一个非营利性独立基金会，它无法发布“企业版”。
- 今天，成员公司在 Apache 许可的 upstream 项目之上构建“企业产品”。其中一些是驱动程序，用于在专有组件中公开功能。
2016 年“不采用开源核心”意味着什么？什么是可接受的，什么是不可以接受的？
Thierry Carrez 认为现在是时候更新 OpenStack 中可接受的官方项目是什么了。
- 它应该具有完全功能性的生产级开源实现
- 如果您需要专有软件或商业实体才能完全使用该项目，那么它不应被 OpenStack 接受为官方项目。
  - 这些项目仍然可以是非官方项目，并且仍然可以由 OpenStack 基础设施托管。
Doug Hellmann 提出 Poppy [11]，它正在申请成为 OpenStack 的官方项目。
- 内容分发网络的包装器，但没有开源解决方案。
- 这是否可以成为一个官方项目，或者是否是开源核心？
完整讨论串：http://lists.openstack.org/pipermail/openstack-dev/2016-February/085855.html

最近在服务目录、API 标头、API 端点，甚至不同资源中的类似命名的资源（例如备份）中出现了一些问题，所有这些问题都围绕着一个关键问题：分布式团队和命名冲突。
每个项目都有一个唯一的名称，该名称由 OpenStack 命名空间中的 git 仓库保证。
希望用通用名称（例如 nova/compute）替换项目名称
- 服务目录
- api 标头
我们有的选项是
- 使用我们已经有的代码名称：nova、glance、swift 等。
  - 优点：解决了冲突问题。
  - 缺点：您需要一个秘密解码环才能知道一个项目做什么。
- 拥有常用名称的注册表。
  - 优点：我们可以在任何地方安全地使用通用名称，而不必担心将来发生冲突。
  - 缺点：又一个争论点。
社区中的各种人员批准对常用名称的注册表。也许在治理 projects.yaml 文件中 [12]？
- 此列表仅包含技术委员会的官方项目，因此只有这些项目才能保留通用名称。
OpenStack Client 已经将这些通用名称编码到项目中 [13]。
完整讨论串：http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html

Ekko 的目标是提供 Nova 实例的增量块级备份和恢复。
有两个具有重叠目标的地方
- Cinder 卷，无需使增量备份依赖于它。
- Nova 实例
  - OpenStack Freezer 今天利用 Nova 的快照功能。
  - Ekko 将利用 Nova 实例的实时增量块级备份。
Jay Pipes 开始讨论这两个项目（Freezer 和 Ekko）协同工作，以确保它们的 REST API 端点不重叠。拥有两个执行备份的 API，实际上是相同的，这不好。
Ekko 的创建者认为需要另一个备份项目，因为“实际实现和最终结果大相径庭”，即使它们是相同的 API 调用。
Jay 不喜欢今天存在以下端点
- Freezer 的 /backups
- Cinder 的 /{tenant_id}/backups
这些端点会带来糟糕的用户体验，并且令人困惑。
当前的治理模型并不能阻止项目的竞争。因此，如果两个项目在 API 端点上重叠，则应尝试协作。
完整讨论串：http://lists.openstack.org/pipermail/openstack-dev/2016-January/084739.html