OpenStack 开发邮件列表摘要 1 月 14-20 日

Mike Perez

2017 年 1 月 20 日

SuccessBot 说

stevemar 1 : Keystone 开放的 bug 数量小于 100！
morgan 2 : 良好的策略会议，提供了历史和背景信息，澄清了很多困惑
通过 OpenStack IRC 频道发送消息“#success <message>”告诉我们您的成功。
全部

FIPS 合规性

之前的讨论 3 讨论了启用联邦信息处理标准 (FIPS)。
各种 OpenStack 项目会调用 md5 函数。并非出于安全目的，只是哈希生成，但即使这样也会阻止启用 FIPS。
针对最新版本的 Python，已经提出了一种补丁，允许用户设置这些函数是否用于安全目的 4 。
- 该补丁要到下一个版本的 Python 才会发布，但对于当前的 RHEL 和 CentOS 版本来说已经可用。
- 我们将创建一个 md5 的包装器，其中包含一个 useforsecurity=False 参数，以检查 hashlib.md5 的签名。
前进的步骤
- 创建包装器
- 将 OpenStack 项目中的所有 md5 调用替换为该包装器。
不幸的是，该补丁 4 自 2013 年以来就停止进展。我们应该先将其合并。
- 即使该补丁发布，也需要一段时间才能被采用，因为它将发布在 Python 3.7 中。
完整线程

刷新和重新验证 API 兼容性指南

在上次 TC 会议 5 中，一个用于支持 API 兼容性的标签正在审核 6 。
该标签使用过时的 API 指南来评估项目 7。
- 已经发布了一份审核，以刷新这些指南 8 。
- API 兼容性是 OpenStack 互操作性的基本方面。我们不仅需要做到正确，还需要确保我们理解它。
完整线程

基础服务

在 OpenStack 中，所有组件都可以假定一些外部服务不存在且不可用（例如，消息队列、数据库）。
架构工作组已经开始了这项工作 9 。
这个提案 10 是我们进行更具战略性的基础服务讨论的前提。
审查该提案和/或加入架构工作组会议 11
一旦确定，技术委员会将进行最终讨论和批准。
完整线程

改进供应商可发现性

在之前的技术委员会会议中，大家一致认为需要改进供应商的可发现性。
目前通过 OpenStack Foundation 市场实现这一点 12 。
- 该市场由社区驱动的项目驱动程序日志提供支持，这是一个大型 JSON 文件 13。
社区中的许多人不知道市场的运作方式，并且对项目本身没有拥有权感到不满。
本次讨论的目标是使该过程比现在更加社区驱动。
建议：将驱动程序日志拆分为较小的 JSON 文件，这些文件位于每个项目内部以进行维护。
- 项目将设置如何验证此列表中的供应商。
- 目前有第三方的 CI 作为验证选择的趋势 14。
完整线程

OpenStack PTL 提名现已开放！

将开放至 2017 年 1 月 29 日 23:45 UTC。
候选人必须提交一个文本文件到 openstack/election 仓库 15
- 文件名约定为 $cyclename/$projectname/$ircname.txt。
- 要符合资格，您需要在 Neutron-Ocata 时间段（2016 年 4 月 11 日 00:00 UTC 至 2017 年 1 月 23 日 23:59 UTC）期间向相应程序的项目提交一个被接受的补丁 16。
有关提名流程的更多信息 17
批准的候选人将列出 18。
选民应在 Gerrit 中确认他们的电子邮件地址 19 在设置 ←联系信息 ←首选电子邮件中，截止日期为 2017 年 1 月 25 日 23:59 UTC。
完整线程

创建 stable/ocata 分支的过程

如前所述 20，团队可以在准备就绪时设置稳定分支。
发布团队本周期不会自动设置分支。
- 团队内的发布联络人需要告知何时准备好。
- PTL 或发布联络人可以通过向 openstack/releases 仓库提交补丁来请求新分支，指定要用作分支基础的标记版本。
项目应该分支的指南
- 使用周期里程碑发布模型的项目应在 RC1 标签请求（目标周为 R-3 周，因此使用 2 月 2 日作为截止日期）时包含对其稳定分支的请求。
- 库项目应在本周与最终发布一起或稍后分支（使用 1 月 19 日作为截止日期）。
- 我将在所有周期里程碑项目分支后不久分支 requirements 仓库。在 requirements 仓库分支并打开主 requirements 列表后，未分支的项目将使用 Pike requirements 进行测试，因为 requirements 主分支会推进而 stable/ocata 保持稳定。不要延迟创建 stable/ocata 分支，否则可能会导致 stable/ocata 或主分支中的 CI 作业失败。
- 使用周期跟踪发布模型的项目应在 R-0（2 月 23 日）之前分支。在跟踪截止日期前的最后两周应用于最后的修复，这些修复需要回移植到分支中以创建最终发布。
- 其他项目，包括使用周期中间发布和独立项目创建分支的项目，应在准备好声明最终版本并开始处理与 Pike 相关的更改时请求其稳定分支。这必须在最终发布周之前完成，使用 2 月 16 日作为截止日期。
有关如何格式化分支规范的更多详细信息，请参阅 openstack/releases 目录中的 README.rst 文件。
完整线程

为什么项目仍然试图避免 Barbican？

一些项目希望实现自己的密钥存储，以避免 Barbican 或避免对其产生依赖。
- 一些开发人员这样做是为了简化操作员的生活。
Barbican 的优点
- Barbican 已经存在多年，并由几家公司部署，这些公司可能已经过安全审计。
- Barbican 涉及的大部分技术已被证明是安全的。这已由 OpenStack 自己的安全团队分析过。
- 不需要硬件 TPM，因此没有硬件成本。
- 几项服务提供了使用 Barbican 的选项，但不是强制要求。
Barbican 问题的反馈
- 依赖于无法保证在部署中存在的东西。
  - 基础服务提案 9 可以帮助解决这个问题。
- OpenStack 特定解决方案。一些公司正在使用与其他系统集成的解决方案
  - Keywhiz 21 与 Kubernetes 及其现有系统一起工作。
- Devstack 插件只是设置 Barbican。它实际上并没有配置任何现有服务来使用它。
- 没有固定的密钥管理器用于测试。Barbican 团队对此进行了反驳，因为它不安全。
- API 稳定性与版本 2 ←3 的更改没有弃用路径或保证。
- 令牌对用户是开放式的。Keystone 和 Barbican 需要更紧密地配合。
Castellan 提供了密钥管理的抽象，但目前只有 Barbican。
Rackspace 最近发布了 Barbican。现在执行 HA 部署可能更容易。
完整线程

POST /api-wg/news

新指南
- 准确的状态码与向后兼容性 22
- 修复浏览器中没有示例文件 23
冻结指南提案
- 添加关于状态与状态使用情况的指南 24
- 澄清版本中的状态值 25
- 添加无效查询参数的指南 26
正在审核中
- 添加关于布尔名称的指南 27
- 定义分页指南 28
- 添加 API 功能发现指南 29
完整线程

R-4 周（1 月 23 日至 27 日）发布倒计时

重点
- 本周开始所有基于里程碑的项目的功能冻结。
- 在此之后不应着陆任何功能补丁。
- PTL 可以授予例外。
- 开始软字符串冻结。
  - 审查团队应拒绝对用户界面字符串的任何修改。
- 开始需求冻结。
  - 仅允许关键需求和约束更改。
发布任务
- 准备所有客户端库的最终发布和分支请求。
- 审查稳定分支是否有未发布的变化，并准备这些发布。
- 基于里程碑的项目应确保 $project-release gerri 组的成员资格与将完成项目发布的团队保持最新。
常规说明
- R-3 周的 RC1 目标只有一周后冻结。
重要日期
- Ocata 3 里程碑，功能和需求冻结：1 月 26 日
- Ocata RC1 目标：2 月 2 日
- Ocata 最终发布候选人截止日期：2 月 16 日
- Ocata 发布计划 30
完整线程