Success Bot Says

• Sdague: nova-network 已弃用 [1]
• Ajaeger: OpenStack 在 Transifex 上的内容已被移除，translate.openstack.org 上的 Zanata 已被证明是一个稳定的平台，供所有翻译人员使用，因此不再需要 Transifex。
• 全部

向后兼容性后续讨论

• 近期关于客户端和库向后兼容性的会议协议
  • 客户端需要与所有版本的 OpenStack 以及云进行通信。
  • Oslo 库已经需要进行向后兼容性处理。
  • 我们大约 1% 到 50% 的部署尝试进行原地升级，例如 Nova 升级，然后 Neutron 升级。但现在 Neutron 必须与 Nova 升级后的库一起工作。
• 我们应该支持原地升级吗？如果支持，我们需要至少 1 个或多个版本的兼容性，例如 Mitaka Nova 可以运行 Newton Oslo+客户端库。
  • 如果我们不支持原地升级，部署方法必须设计为避免出现客户端或 N 个服务中的一个在单个 python 环境中被升级的情况。所有客户端和服务必须在单个 python 环境中一起升级，或者根本不升级。
• 如果我们决定支持原地升级，我们需要弄清楚如何有效地测试它；它随着我们选择支持的稳定版本数量线性增长。
• 如果我们决定不支持，我们就无需再考虑 OpenStack 版本之间的交叉兼容性。
• 我们仍然必须在单个更改上保持向后兼容性。
• 完整线程

Newton 安装指南计划

• 承接之前的 Dev Digest [2]，大帐篷正在扩大，我们的文档团队希望项目维护自己的安装文档。这应该在仍然提供高质量的有效工作安装信息和团队努力的一致性的前提下完成。
• 安装指南团队在峰会上举行了一次会议，会议非常火爆，并为 Newton 制定了一些明确的目标。
• 正在讨论的两个问题
  • 如何处理现有的安装指南。
  • 创建一个允许项目在其自己的仓库中编写安装文档的方式。
• 所有指南都将从各个仓库渲染，并显示在 docs.openstack.org 上。
• 文档团队对项目编写安装指南有建议
  • 基于现有的安装指南架构构建，这样就无需重复造轮子。
  • 遵循文档约定 [3]。
  • 使用相同的名为 openstackdocstheme 的主题。
  • 使用安装指南使用的相同发行版。从源代码安装是一种替代方案。
  • 指南应该进行版本控制。
  • RST 是首选的文档格式。RST 也易于翻译。
  • 通用命名方案：“X 服务安装指南” – 其中 X 是您的服务名称。
• 选择的 URL 格式是 docs.openstack.org/project-install-guide/RELEASE/SERVICE。
• 有很多后续工作项目 [4]，欢迎志愿者！
• 完整线程

Magnum 任务声明的拟议修订

• 来自峰会讨论，对 Magnum 的任务声明提出了一项修订 [5]。
• 想法是缩小 Magnum 的范围，以便团队能够专注于使流行的容器编排引擎 (COE) 软件与 OpenStack 配合得很好。允许用户设置由 COE（例如 Swarm、Kubernetes、Mesos 等）管理的云容量集群。
• 弃用 Magnum API 中的 /containers 资源。任何新项目都可以承担创建抽象一个或多个 COE 的 API 服务的目标。
• 完整线程

支持 Go 编程语言

• Swift 社区有一个名为 feature/hummingbird 的 git 分支，其中包含 Swift 的一些部分用 Go 重新实现。 [6]
• 目标是在巴塞罗那峰会上准备好一个合理的准备合并的功能分支。峰会结束后不久，计划将 Go 代码合并到主分支。
• 将修订后的技术委员会决议将建议 Go 作为 OpenStack 项目中受支持的语言 [7]。
• 一些技术委员会成员表示希望看到技术优势，以抵消添加该语言导致的社区碎片化和基础设施任务增加。
• 一些悬而未决的问题
  • 我们如何运行单元测试？
  • 我们如何提供代码覆盖率？
  • 我们如何管理依赖项？
  • 我们如何构建源代码包？
  • 我们应该构建某种格式的二进制包吗？
  • 如何管理树内文档？
  • 我们如何处理日志和消息字符串的翻译？
  • DevStack 如何将项目作为门控作业的一部分进行安装？
• Designate 也在研究将单个组件迁移到 Go。
  • 最好有 2 个案例来帮助避免将项目特定的假设融入到测试和构建接口中。
• 完整线程

R-21 周倒计时，5 月 9-13 日

• 重点
  • 团队应该专注于完成 Mitaka 周期中未完成的工作。
  • 宣布峰会上的计划。
  • 完成规范和蓝图。
• 常规说明
  • 希望更改其发布模型的项目团队应在 Newton-1 里程碑之前进行标记。可以通过向治理仓库中的 projects.yaml 文件提交补丁来完成此操作。
  • 发布公告电子邮件建议将其标签从“release”切换为“newrel” [8]。
• 发布操作
  • 发布联络人应将他们的姓名和联系信息添加到此列表 [9]。
  • 发布联络人应让他们的 IRC 客户端加入 #openstack-release。
• 重要日期
  • Newton 1 里程碑：R-18 6 月 2 日
  • Newton 发布计划 [10]
• 完整线程

Trove 中图像构建的讨论

• Trove 团队收到的常见问题是新用户如何以及在哪里获取来试验 Trove 的客户镜像。
  • 目前文档存在于多个位置 [11][12]，但仍然可以改进。
• Trove 有一个规范提案 [13]，用于使用 libguestfs 方法构建镜像，而不是使用当前的 diskimage-builder (DIB)。
  • 所有替代方案都应该是等效且可互换的。
  • Trove 已经为所有受支持的数据库使用 DIB 准备了元素，但这些元素未打包供客户使用。这样做只需提供一个元素即可从固定位置安装客户代理软件即可。
  • 我们应该了解在切换工具链时 DIB 的不足之处（如果有的话）。这可以基于 Trove 和 Sahara 的经验。
• OpenStack 基础设施团队已经成功使用 DIB 了一段时间，因为它是一个灵活的工具。
  • 默认情况下 Nova 禁用文件注入 [14]
  • DevStack 不允许您启用 Nova 文件注入，并将其强制关闭 [15]。
  • 允许使用 yum 或 debootstrap 进行引导
  • 选择现有镜像的文件系统。
• 让我们修复 Trove 遇到的 DIB 问题，并避免重复造轮子。
• DIB 有什么问题，以及它们如何阻止 Trove/Sahara 用户今天构建镜像？
  • Libguestfs 以一种可预测的方式在 libguestfs 创建的干净的辅助虚拟机中操作镜像。
    • 隔离是 DIB 为了提供速度/降低资源使用而放弃的。
  • 可以进行原地镜像操作（软件包安装、配置声明），而无需解压缩或重新压缩整个镜像。
    • 制作一个修改现有镜像并使其原地的 DIB 元素是微不足道的。
  • DIB 脚本的配置设置以自由格式的环境变量传递，对于新用户来说可能难以理解和记录。Libguestfs 需要更正式的参数传递。
  • 易于“给我一个镜像。我不在乎调整旋钮”。
    • OpenStack Infra 团队已经为此提供了一个包装器 [16]。
• Sahara 支持几个与图像生成相关的案例
  • 在 Nova 中预集群生成时打包镜像。
  • 在 Nova 生成后从“干净”操作系统镜像构建集群。
  • 在 Nova 生成后验证镜像。
• 在 Sahara 峰会上，讨论了一个使用 libguestfs 而不是 DIB 的计划，目的是为任何插件定义一个线性、幂等的步骤集来打包镜像。
• 维护两套图像构建代码将是一个巨大的缺点。
• 如果我们在几个版本后决定 libguestfs 性能不佳，并决定使用新工具，会发生什么？由于 DIB 是一个 OpenStack 项目，Trove 应该考虑支持一种标准的方式来构建镜像。
• Trove 峰会讨论的结果是同意通过使构建客户镜像更容易来改进图像构建器，利用 DIB。
  • 已提出项目仓库提案 [17][18]
• 完整线程