SuccessBot 说

• Bknudson：我们去掉了 keystone CLI [转而使用 OpenStack Client]
• jrichli：Swift 加密已经通过了所有功能测试。
• Bauzas：只有极少数 Nova 变更缺少 reno 文件，团队现在非常熟练地添加它们。
• Odyssey4me：OpenStack-Ansible 现在有一个 Designate 角色，可以进行测试 [1]。
• ttx：Glance 是第一个发布 RC1 的项目！
• Mugsie：mlavalle 完成了 Nova/Neutron/Designate DNS 集成，以及文档和客户端。
• Odyssey4me：OpenStack-Ansible 发布了 Kilo 11.2.11。这是我们第一次使用发布团队进行发布，我们非常喜欢！
• Odyssey4me：OpenStack-Ansible Liberty 12.0.8 已发布。
• 通过 IRC 发送消息“#success [插入成功案例]”告诉我们你的成功案例。
• 所有成功案例

当前 PTL 选举状态

• 重要日期
  • 选举开始：2016-03-18 00:00 UTC
  • 选举结束：2016-03-24 23:59 UTC
• 只有一个候选人的项目：41 个
• 没有 PTL 候选人的项目
  • EC2-API
  • Stable Branch Maintenance
  • Winstackers
• TC 将为没有候选人的项目任命新的 PTL [2]
• 已确认的候选人 [3]

配额 – 服务与库

• 有一个关于跨项目配额工作的规范 [4]，正在寻求反馈，以确定是作为服务还是库进行推进。
• 服务
  • 一个新项目，用于管理所有使用该服务项目的配额。
  • 它将负责处理所有配额逻辑的强制执行、管理和数据库升级。
  • 但是，所有项目都将严重依赖这个服务。
• 库 – 两种方式
  • 不处理数据库模型
    • 也许是一个 ABC，甚至是一些标准实现向量，可以导入到项目空间中。
    • 该项目将拥有自己的配额 API，驱动程序将强制执行不同的类型（例如，扁平配额驱动程序或分层配额驱动程序），并具有自定义/项目配置。
    • 项目维护自己的数据库和升级。
  • 一个具有数据库表模型的库，项目可以从中导入。
    • 项目将拥有一个方便的表格结构概述。
    • 项目拥有自己的 API 并通过导入这个半定义的结构在树内实现驱动程序。
    • 项目维护自己的升级，但会受到公共仓库的影响。
• 或者，只需避免所有这些，提供指导原则即可。
• 过去曾有人提出过一个服务，例如 Boson [5]。
• Tim Bell 最初提出库会更好。
  • 如果我们无法就库达成一致，我们不太可能就服务达成一致。
  • 这将允许一致地实现嵌套配额和用户配额。
• 对于像 Trove 这样需要对所有项目配额进行一致锁定的项目，首先需要解决像 Nova 这样需要解决竞态条件的问题。
• 之前的一次峰会上提出的库的主要问题是如何将数据库表管理与项目拥有的现有表关联起来。虽然这并非无法解决，但我们需要考虑哪些工具可以帮助解决这个问题。
• 完整线程

SuccessBot 说

• Ajaeger：所有作业已从 bare-trusty 迁移到 ubuntu-trusty。
• Clarkb：基础设施现在正在运行 logstash 2.0
• 通过 IRC 发送消息“#success [插入成功案例]”告诉我们你的成功案例。
• 所有成功案例

跨项目

• API 指南已准备好进行审查
  • Header 非增殖 [1]
  • 微版本客户端交互指南 [2]

选举季，PTL 和 TC

• PTL 选举
  • 重要日期
    • 提名开始：2016-03-11 00:00 UTC
    • 提名结束：2016-03-17 23:59 UTC
    • 选举开始：2016-03-18 00:00 UTC
    • 选举结束：2016-03-24 23:59 UTC
  • 每个项目团队必须每 6 个月选举一次 PTL。
  • 更多信息以及如何提交您的候选资格 [3]。
• TC 选举
  • 重要日期
    • 提名开始：2016-03-25 00:00 UTC
    • 提名结束：2016-03-31 23:59 UTC
    • 选举开始：2016-04-01 00:00 UTC
    • 选举结束：2016-04-07 23:59 UTC
  • 根据 TC 章程的规定 [4]，我们更新 7 个 TC 席位。席位有效期为一年。
  • 更多信息以及如何提交您的候选资格 [5]。
• 完整线程

stable:follows-policy 标签已正式启用，项目需要开始申请它

• 这在治理文件中是正式的 [6]。
• 遵循稳定分支策略 [7] 的项目应开始申请。
• 完整线程

本周（3 月 14-18 日）的发布倒计时 R-3

• 重点
  • 遵循 cycle-with-milestone 模型的项目团队
    • 本周正在准备他们的第一个 Mitaka 发布候选版本。
    • 一旦解除 master 的压力大于回溯修复错误的成本，就应该使用 (X.Y.Z.0rc1) 进行标记。
    • 发布团队将从发布候选版本标签点创建稳定分支。
  • 遵循 cycle-with-intermediary 模型的项目团队
    • 确保您至少有一个 mitaka 发布版本。
    • 确定在 Mitaka 周期结束前是否需要另一个发布版本。
  • 所有未登陆的特性冻结例外情况都应等到 Newton。
• 常规说明
  • 全局需求列表已冻结。如果您需要更改依赖项，以进行错误修复，请在变更请求中提供足够的详细信息，以便需求审查团队评估该变更。
  • 面向用户的字符串已冻结，以便翻译团队有时间完成他们的工作。
• 发布操作
  • 发布团队已开始为库创建 stable/mitaka 分支。
  • 请关注邮件列表线程 [8] 以确认并批准用于创建分支的版本号。
    • 这仅包括具有 release:managed 标签的项目。
    • 其他项目可以在线程中发布请求他们自己的分支。
• 重要日期
  • RC 目标周：R-1，3 月 28 日至 4 月 1 日
  • Mitaka 最终发布：4 月 4 日至 8 日
  • Mitaka 发布计划 [9]。
• 完整线程

提醒：WSME 尚未积极维护

• Chris Dent 和 Lucas Gomes 一直在积极验证错误修复并保持 WSME 的运行，但他们不再感兴趣或没有时间继续。 并且发现它从未真正达到以下状态
  • WSME 代码易于理解和维护。
  • WSME 提供正确的 HTTP 处理（特别是响应状态和标头）。
  • WSME 具有适合创建基于现代 Python 的 Web 应用程序的架构。
• 有人建议使用它的 24 个不同的 OpenStack 项目转向其他东西。
• 选择 WSME 的一个主要原因是它对 XML 和 JSON 都有支持，而无需应用程序代码显式地执行任何操作。
  • 社区已决定停止提供 XML API 支持，并且已经使用其他工具来提供类似于 WSME 的解析和验证功能
    • JSONSchema
    • Voluptuous
• 完整线程

SuccessBot 说

• ttx：Mitaka-3 完成了。
• Odyssey4me：OpenStack-Ansible Liberty 12.0.7 已发布 [1]。
• johnthetubaguy：Nova 现在只剩下四个待处理的蓝图，用于特性冻结 [2]，至少比早上好。
• Russellb：在 OVN 中获得了一组正在工作的 OVS 流，可以立即将安全组更改应用于现有连接。
• 通过 IRC 发送消息“#success [插入成功案例]”告诉我们你的成功案例。
• 全部

跨项目

• 配额和嵌套配额工作组
  • 会议 [3]
  • 规范 [4]

Outreachy 2016 年 5 月至 8 月：资金和导师的征集

• Outreachy [5] 帮助在自由和开源软件中代表性不足的群体参与进来，方法是将实习生与上游社区中成熟的导师配对。
• 在下一个周期（2016 年 5 月 23 日至 8 月 23 日）中，OpenStack 有 10 名志愿者导师。
  • 了解更多信息并申请成为导师 [6]。
• 潜在的赞助者已经联系了我们，但由于申请人数增加，我们需要更多赞助者。
  • 每个实习生为期三个月的项目费用为 6,500 美元。
  • OpenStack 基金会已确认参与。
  • 了解更多信息并申请成为赞助者 [7]。
• 无论如何，请帮助传播信息！
• 完整线程

更改微版本标头

• API 工作组希望更改用于微版本的标头格式，以便在太多项目使用它们之前使其更具未来兼容性。
  • 建议的指南 [8]。
• 这出现在另一个关于标头非增殖的指南中 [9]。
• 经过大量的讨论，并且在项目已经部署微版本（Nova、Ironic、Manila）的情况下，建议从
  • X-OpenStack-Nova-API-Version: 2.11
  • OpenStack-Compute-API-Version: 2.11
• 更改为
  • OpenStack-API-Version: compute 2.11
• 这使我们能够为多个服务使用一个标头名称，并避免了标头非增殖指南 [9] 中描述的一些问题。
• 完整线程

OpenStack 贡献者奖

• 基金会希望推出一些非正式的古怪奖项，以表彰我们所有人为使 Openstack 卓越所做的宝贵工作。
• 在许多不同的领域值得庆祝的情况下，社区中需要一些关爱的几个主要部分
  • 那些可能不知道自己受到重视的人，特别是新贡献者
  • 那些是团结社区的积极粘合剂的人
  • 那些与他人分享他们辛勤获得的知识并提供指导的人
  • 那些挑战假设并让我们思考的人
• 提名您认为值得获得奖项的人 [10]！
• 完整线程

Mitaka 中 Python 3 的状态

• 在 Mitaka 周期中，有 13 个服务已移植到 Python 3：Cinder、Glance、Heat、Horizon 等。
• 仍有 9 个服务需要移植
• 下一个里程碑：功能和集成测试
• “移植到 Python 3”意味着所有单元测试都通过了 Python 3.4，这由投票门禁作业验证。在 Python 3 上运行应用程序并不足以进行生产。
• 阅读完整的状态帖子 [11]，作者为 Victor Stinner。
• 加入 Freenode 频道 #openstack-python3 以讨论和提供帮助！
• 完整线程

发布说明的受众

• 我们有 3 个潜在的发布说明受众
  • 使用库或直接使用其他代码的开发人员。
  • 部署者和操作员。
  • 最终用户。
• 正在讨论两种类型的文档
  • Reno [1] 用于发布说明 [2]
    • 请记住，受众 *不是* 那些不一定查看代码或基于我们生成的库编写应用程序的人。
    • 突出显示部署者和操作员需要的信息，例如配置选项或服务行为的更改。
    • 描述最终用户可能需要了解的 REST API 更改。
  • 树内开发人员文档 [3] 用于开发人员。
    • 内部细节、库 API 更改等——部署者看不到的任何更改。
• 这两组文档的用途不同，因此我们需要考虑在每个文档中发布哪些信息。
• 完整线程 [4]

将设计峰会分离的提案

今天

• 从一开始，我们在设计峰会上进行面对面交流，讨论开发周期，设定目标并组织未来 6 个月的工作。
• 同时举行了一个更传统的会议，以确保上游和下游社区之间的互动。

当前问题

• 对于开发人员
  • 很难专注于上游工作，因为来自会议的许多干扰。
  • 因此，峰会效率较低，我们形成了中期周期来填补我们的重点。
• 对于公司
  • 将所有开发人员飞往昂贵的城市和会议酒店参加峰会成本很高。——峰会位置接触各地的用户目标并不一定与设计峰会位置目标一致。
  • 没有足够的时间在最新版本的基础上构建产品。

• 用户没有足够的时间尝试新版本以提供反馈。
• 找到能够容纳这两个活动的场地变得越来越复杂。

如何拆分活动

• 第一个活动将面向 OpenStack 的上游技术贡献者。
  • 将在一个更简单、更精简的环境中举行，让所有 OpenStack 项目团队在单独的房间中开会，但在一个共同举办的活动中，可以轻松进行跨项目的临时讨论。
  • 它将位于更靠近贡献者中心的位置，在成本较低的位置。
  • 这将在前一个周期发布前两周左右发生。周期之间有很多重叠。一个周期的工作从前一个周期的功能冻结开始，而还有 5 周的时间。大多数人在 RC1 之后转而全职投入下一个周期。在那个时间之后组织活动让我们能够最好地组织工作并启动新周期。它还允许我们利用一起的时间来快速解决发布关键的最后一刻问题（如果出现此类问题）。
• 第二个活动将是主要的下游业务会议。
  • 包括高端主题演讲、市场和分组讨论会。
  • 在发布后两个或三个月组织，以便给下游用户时间部署和构建基于该发布的产品。
  • 这将更好地让我们收集有关最新发布的反馈，并收集下一个周期的需求。
  • 希望参与会议的一组贡献者可以收集和转达反馈给其他团队成员（类似于周期中期运营商会议）。
• 这种划分应该减少周期中期活动的数量，但是，如果仍然需要，它们可以在会议活动中进行（会议活动位于周期中间）。
• 这种划分意味着我们需要错开活动和周期。巴塞罗那和美国第一季度峰会之间的时间很长，所以想法是利用这段时间插入一个较小的周期（Ocata），在 2017 年 3 月初发布，并在 P 周期的开始，即 2017 年 2 月中旬举行第一次特定的贡献者活动。考虑到 2016 年和 2017 年已经计划的活动，这是我们能够实现过渡的最早时间。我们将在巴塞罗那举行一次规模较小的设计峰会，以规划较短的周期。
• 运营商周期中期会议将继续举行。

提出的担忧和解答

• 这创建了两个活动而不是一个。造成社区分裂，开发者跳过主会，而非开发者不向特定贡献者活动提供任何反馈。
  • 主会仍然会有很多战略讨论。
  • 我们将在那里回顾 N-1 发布版，并开始为 N+1 发布版制定计划和跨项目主题。
  • 我们不需要所有开发者都在那里，但仍然需要相当一部分开发者，每个团队都有代表，这样我们才能进行这些战略和跨项目讨论。
  • 想要保持与开发联系的人仍然可以只参加一次旅行，因此社区分裂是不必要的。我们仍然会在主会中得到充分代表。
• 失去主会作为资助开发者旅行的借口。有些开发者只被派往设计峰会，因为主会同时举行。
  • 如果你不得不假装参加峰会才能参加设计峰会，那么其中涉及欺骗。你应该与你的雇主讨论在哪次活动中参加对你最有价值。
  • 基金会也有旅行支持计划来弥补差距 [5]。
• 担心以美国为中心（从“更接近贡献者的质量中心”翻译而来）。这使得旅行成本更便宜，但代价是增加了非美国社区的旅行成本。
  • 目标是“最小化和*平衡*现有贡献者的旅行成本”。仍然会有一些大陆轮换，但我们需要平衡成本和公平性。
• 失去周期中期精神。有些人非常喜欢当前的周期中期活动：分离的小型活动，只有你的小团队在场。这种划分似乎减少了对此类活动的可能性、必要性或资金。
  • 虽然希望提议的格式能够让我们满足所有团队社交需求，但确实会有其他人也在场，而且它会感觉不那么排他性和特殊。
  • 权衡是让人们聚在一起鼓励跨项目合作并打破孤岛。
• 完整线程 [6]

OpenStack 运营商

• OpenStack 周期中期运营商会议的收获：第一次就成功了 [1]
• OpenStack 升级教程：11 个陷阱和解决方案 [2]

2016 年“无 Open Core”（继续）

• 继续讨论 Poppy，Doug Hellmann 指出 Poppy 团队已经完成了我们要求的一切。当前的治理强调项目的社会方面和社区互动。即使 Poppy 团队遵循了所有要求，仍然告诉他们“他们不是 OpenStack”也是令人沮丧的。
• Sean Dague 提到 Neutron 等解决方案有一个开源解决方案。可能需要一些工作，但至少有一个开源解决方案用于测试。
• Dean Troyer 提出我们有 Cinder，其中包含商业存储驱动程序。即使没有这些存储驱动程序，Cinder 仍然有用。
• Poppy 的开源实现选项 OpenCDN 目前是一个废弃的项目。
• 完整线程：http://lists.openstack.org/pipermail/openstack-dev/2016-February/085855.html

升级 paste.ini 中大量内容的影响

• 最近出现了一组跨域资源共享 (CORS) 补丁 [3]，这向 paste.ini 添加了大量内容。
• Paste.ini 是运营商可以更改的配置。
  • 其中包含大量复杂的内容，这些内容可能会在未来的发布版本中发生变化，这确实是个问题。
  • 弃用内容也具有挑战性。
  • 为什么这些选项不能只是 CORS 中间件的默认设置？
    • 一些项目，如 Ironic，要求不要规定标头，例如，如果 Ironic 使用 Keystone 以外的其他东西，则需要不同的允许标头。
    • 但是，Keystone 是 defcore，因此默认设置应该在那里有用。然后可以灵活地在其他身份验证选项之上进行操作。
• 我们接下来该怎么办？
  • 选项 1：按原样实施，保持一致性，在 Newton 中修复它们。
    • 这在 Newton 中无法修复，因为它需要在接下来的三个版本中弃用。
  • 选项 2：尝试在 Mitaka 2 中修复 CORS 中间件设置默认值，并允许项目覆盖 [4]。
    • 这将需要对许多项目进行补丁 [5]。谁可以帮忙？
• 完整线程：http://lists.openstack.org/pipermail/openstack-dev/2016-February/086746.html

[1] – http://superuser.openstack.org/articles/takeaways-from-the-openstack-mid-cycle-ops-meetup-first-time-s-the-charm

[2] – http://superuser.openstack.org/articles/openstack-upgrading-tutorial-11-pitfalls-and-solutions

[3] – https://review.openstack.org/#/c/265415/1

[4] – https://docs.openstack.org/developer/oslo.config/generator.html#modifying-defaults-from-other-namespaces

[5] – http://governance.openstack.org/reference/projects/index.html

SuccessBot 说

• dhellmann：[1] 已经发布了发布历史和即将发布的发布计划。
• ttx：治理变更现在在 #openstack-dev 中公布，以提高普遍的认识！
• jklare：刚刚合并了 Mitaka 周期中第一个 opentack-chef cookbook 补丁！重构了 4.229 行代码，删除了 18.678 行！
• johnthetubaguy：Nova 子团队开始照顾自己，并有效地向更广泛的社区报告他们的进度
• 所有：https://wiki.openstack.org/wiki/Successes

删除 KEYSTONE_CATALOG_BACKEND – 此外，更新你的 Devstack 插件

• Devstack 对 Keystone 模板化服务目录有一些半成品的支持。
• 为了清理 Devstack 的一部分，我们正在删除它 [2]。
• 这破坏了所有引用 KEYSTONE_CATALOG_BACKEND 变量的 Devstack 插件。
• 该变量将保留到 Newton 开发开放为止。
• 完整线程：http://lists.openstack.org/pipermail/openstack-dev/2016-February/086272.html

向新的按区域划分的 PyPI、wheel 和 APT 镜像致敬

• 我们有了基于 AFS 的一致的按区域划分的 PyPI 和 API 存储库的新镜像，其中包含额外的 wheel 存储库，其中包含 global-requirements 中所有模块的预构建 wheel。
• 你不会注意到任何差异，除了作业应该会更快、更可靠。
• 完整线程：http://lists.openstack.org/pipermail/openstack-dev/2016-February/086295.html

R-7 周倒计时，2 月 15-19 日

• 重点：项目团队应专注于完成所有库中的新功能工作。
• 发布操作
  • 我们将严格执行在 2 周后 Mitaka-3 之前的库发布冻结。
  • 检查你的团队管理的客户端库、集成库和任何其他库，并确保最近的更改已发布。
  • 确保 global-requirements 和约束列表是最新的，具有准确的最小版本和排除项。
  • 使用周期中间发布模型的项目需要生成中间发布版本。有关详细信息，请参阅 Thierry 的电子邮件 [3]。
  • 检查 stable/liberty 分支并提交补丁到 openstack/releases，如果你希望它们被包含。
• 重要日期
  • 非客户端库的最终发布：2 月 24 日
  • 客户端库的最终发布：3 月 2 日
  • Mitaka 3：2 月 29 日至 3 月 4 日（包括功能冻结和软字符串冻结）
• 完整线程：http://lists.openstack.org/pipermail/openstack-dev/2016-February/086362.html

为什么使用 Swagger 而不用 WADL

• 继续之前的更新 [4]。
• api-site 的每次构建现在都在运行 fairy-slipper，以从 WADL 迁移到 Swagger。
  • 这些迁移后的 Swagger 文件被复制到 [5]。
• 并非所有文件都能顺利迁移。我们希望团队查看这些迁移后的文件。感谢已经提交修复的那些人！
  • 如果在原始 WADL 中看到问题，请记录它 [7]。
  • 如果在迁移工具中看到问题，请记录它 [8]。
• 基础设施团队正在审查规范 [6]，以便我们能够从 developer.openstack.org 提供 API 信息。
• 你可以加入 #openstack-doc 或 #openstack-sdks 向 nick annegentle 提问
• 完整线程：http://lists.openstack.org/pipermail/openstack-dev/2016-February/086467.html

租户与项目

• Sean Dague 提出 OpenStack 对租户与项目的使用。我们正在过渡到哪个？
• Keystone 正在努力允许 service catalog 中的 project_id [9]。
• Neutron 正在过渡到 project_id。
• 当前的 Ansible OpenStack 模块正在使用项目 [10]。
• OSLO Logging/Context 正在使用项目。
• 完整线程：http://lists.openstack.org/pipermail/openstack-dev/2016-February/086396.html

将设计峰会与 OpenStack 会议分开的提案

• OpenStack 设计峰会最初是作为工作活动开始的。
• 随着 OpenStack 会议越来越注重营销和销售，参加的贡献者往往注意力不集中。
• 一些贡献者提交演讲到会议，因为他们的公司说这是他们参加会议的唯一方式。这部分原因是成本。
• Thierry Carrez（他帮助组织设计峰会）解释说，他一直在努力寻找分离峰会和会议的解决方案，基金会正在最终确定一个草案提案，该提案将推送到社区以征求意见。
• 完整线程：http://lists.openstack.org/pipermail/openstack-dev/2016-February/086007.html

[1] – https://releases.openstack.org
[2] – https://review.openstack.org/#/c/278333
[3] – http://lists.openstack.org/pipermail/openstack-dev/2016-February/086152.html
[4] – https://openstack.org/blog/2016/01/openstack-developer-mailing-list-digest-january-9-15/
[5] – https://developer.openstack.org/draft/swagger
[6] – https://review.openstack.org/#/c/276484/
[7] – https://bugs.launchpad.net/openstack-api-site
[8] – https://bugs.launchpad.net/openstack-doc-tools
[9] – https://review.openstack.org/#/c/279576/
[10] – https://docs.ansible.org.cn/ansible/list_of_cloud_modules.html#openstack

SuccessBot 说

• odyssey4me：OpenStack Ansible Liberty 12.0.5 发布。
• stevemar：Devstack 现在默认使用 Keystone v3。
• boris-42：osprofiler 功能作业通过 [1]。
• odyssey4me：OpenStack Ansible Kilo 11.2.9 发布 [2]。
• odyssey4me：OpenStack Ansible Liberty 12.0.6 发布 [3]。
• 所有：https://wiki.openstack.org/wiki/Successes

跨项目规范

• 所有项目的常见策略场景 [4]。
• 从 Web UI 查询配置 [5]

API 指南

• 不得返回服务端的堆栈跟踪 [6]。

服务类型与项目名称在标头中使用

• 关于我们是否应该在标头中使用服务类型或项目名称存在疑问。一些涉及此问题的审查 [7][8][9][10]。
• 我们应该选择更好地服务于 API 消费者，根据 Dean Troyer 的说法，API 工作组正在朝着正确的方向前进。
• 服务类型作为端点和 API 服务的首要标识符已建立，并且一直是服务目录的工作方式。因此，服务类型应该是首选。
• 完整线程：http://lists.openstack.org/pipermail/openstack-dev/2016-January/085145.html

没有容器的 OpenStack Ansible

• Gyorgy 宣布了一个新的安装程序，用于使用 GPLv3 的 OpenStack Ansible，但没有容器。
  • 由于我们已经有了 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

R-8 周倒计时，2 月 8-12 日

• 重点
  • 距离本周期非客户端库的最终发布还有 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

2016年“不采用封闭核心”

• 在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 – OpenStack的可扩展基于块的备份

• 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

Success Bot Says

• mriedem：nova liberty 12.0.1已发布 [1]。
• OpenStack Ansible Kilo 11.2.7已发布。
• OpenStack-Ansible Liberty 12.0.4已发布。
• 通过 IRC 发送消息“#success [插入成功案例]”告诉我们你的成功案例。
• 所有：https://wiki.openstack.org/wiki/Successes

治理

• 大型项目许可要求澄清 [2]。
• 在测试级别选择加入约束 [3]。
• OSprofiler现在是一个官方的OpenStack项目 [4]。

跨项目

• TC批准
  • 赞成使用OpenStack客户端，弃用单个CLI [5]。
  • 客户端中的clouds.yaml支持 [6]。
• 当前开放的规范：https://review.openstack.org/#/q/status:open+project:openstack/openstack-specs

R-10周倒计时，1月25日至29日

• 重点：在第二个里程碑之后，项目团队应专注于完成新功能的工作并稳定最近的添加内容。
• 发布操作
  • 在M3（5周）之前严格执行库发布冻结。
  • 审查您的团队管理的客户端/集成库和其他库。
  • 确保全局需求和约束列表已更新，并具有准确的最低版本和排除项。
  • 许多项目在stable/liberty分支上未发布更改。检查您的项目 [7]。
• 重要日期
  • 非客户端库的最终发布：2月24日
  • 客户端库的最终发布：3月2日
  • Mitaka-3：2月29日至3月4日（包括功能冻结和软字符串冻结）。
  • Mitaka发布计划 [8]。
• 完整线程： http://lists.openstack.org/pipermail/openstack-dev/2016-January/084678.html

稳定周期：阐述推进该想法

• 在东京峰会上，OpenStack开发主题会议上，人们讨论了共享努力的总体重点，提出了具有稳定项目周期的想法。
• 一个项目可以决定花费一定比例的时间来专注于修复错误、审查积压、重构，而不是完全关注新功能。
• 项目已经有权这样做，但是，也许TC可以致力于正式化这个过程，以便团队在想要时可以参考。
• 一些来自峰会的贡献者认为他们需要技术委员会在这个问题上发挥领导作用，以便他们能够将其卖回给他们的公司。
• 讨论的另一个方面是，健康的应该自然而然地出现功能添加的爆发和偿还技术债务的爆发。
  • 强制执行特定的稳定周期会阻止达到理想状态。
• 完整线程： http://lists.openstack.org/pipermail/openstack-dev/2016-January/084564.html