OpenStack 开发者邮件列表摘要 7 月 23 日至 8 月 5 日

Mike Perez

2016年8月8日

所有项目享有平等机会

OpenStack治理仓库中一项提案 [1]，旨在使OpenStack中的所有内容都基于插件，或者允许所有项目访问相同的内部API。
有些项目具有插件接口，但也具有树中的项目集成。这使得难以了解插件的功能以及应该做什么。
有了“大帐篷”，我们希望转向更扁平化的模式，移除旧的集成状态。
示例
- 标准命令行界面或UI用于设置配额，对于Nova、Neutron或Cinder之外的项目来说很困难。
  - 例如，Horizon中的配额是在“admin → quotas”中设置的，但插件无法放在这里。
  - OpenStack Client 有“openstack quota set –instances 10”这样的命令。
  - 为OpenStack Client做出贡献的Steve Martinelli 已经确认这不是设计使然，而是缺乏贡献者资源所致。
- Tempest插件使用不稳定的资源（例如，设置用于运行测试的用户、项目）。树中的项目受益于任何更改在合并之前都必须通过门控检查。
  - 规范以解决这个问题 [2]。
  - 稳定的接口仍然需要改进，以增加其暴露给插件的内容。这需要一些工作，并且由QA团队优先处理。
    - Tempest中的所有测试都使用稳定的接口。
  - 由于许多插件使用不稳定的接口，QA团队正在尝试保持向后兼容性，直到可用稳定的版本为止，但这并不总是可行的。
  - Tempest.lib [3] 被认为是“稳定的接口”。
鉴于所给示例中正在进行的工作量，似乎没有不同意见反对总体目标，因此不需要全局规则或策略。
已经存在一项策略 [4]，规定了横向团队应如何与所有项目合作。
完整线程和后续线程

建立项目范围的目标

技术委员会成员参加的领导力培训会议的一个结果是，为完成特定的技术任务以使项目同步设置社区范围的目标。
治理仓库中一项变更 [5] 设定了什么样的目标是好的以及团队应该如何处理它们。
提出了两个目标
- 支持 Python 3.5 [6]
- 切换到 Oslo 库 [7]
技术委员会希望为发布设定一个合理的数量的小目标。而不是具有侵入性的自上而下的设计指令，团队可能会抵制。
- 团队可能有一个很好的理由不想或无法实现某个目标。这只需要记录下来，并且不会导致从“大帐篷”中移除。
完整线程

API 工作组新闻

Cinder 正在研究暴露资源能力。
- 规范 [8]
- 补丁 [9]
正在审查的指南
- 开始制定 URI 指南 [10]
- 添加分页参数的描述 [11]
完整线程

大帐篷？

我们是否应该考虑“大帐篷”是否是正确的方法，因为注意到了一些缺点
- 项目因为害怕增加额外的依赖而无法协同工作。
- 重新实现功能，质量很差，而不是标准化。
- 由于政治原因创建了更多的项目，而不是技术原因。
- 跨项目沟通减少。
- 操作员在组装松散的项目时感到痛苦。
- 架构决策在单个项目层面做出。
具体例子
- Magnum 试图不使用 Barbican。
- 在峰会上，Horizon 讨论希望使用 Zaqar 进行更新，而不是轮询，但无法依赖于未广泛部署的子系统。
- 不兼容的虚拟机通信
  - Sahara 使用 ssh，这与租户网络不兼容。
  - Trove 使用 rabbit 来让访客代理与控制器通信。
“大帐篷”的总体目标是使社区更具包容性，这些问题早于“大帐篷”。
真正能够迫使人们采用某个项目的唯一方法是 DefCore，但这会带来一个主要的先有鸡先有蛋的问题。
今天没有发生的是一个共同的标准，所有内容都可以朝着它发展。Clint Byrum 提出的架构工作组可能是一个前进的方向。
技术委员会是在努力提供这一点，但又不干涉太多一个项目，而成员可能没有该项目领域的具体经验。
Sahara 在与其他项目集成方面取得了一些成功。
- Kilo/Liberty 与 Heat 集成以部署集群。
- Liberty/Mitaka 集成了 Barbican。
- 使用 Manila 共享作为数据源。
- Liberty/Mitaka 在 OpenStack Client 中添加了 Sahara 支持。
- 正在进行中，与 Designate 的支持。
完整线程