Success Bot Says

• Clarkb：infra 团队在新的更大服务器上重新部署了 Gerrit。应该可以更快地处理代码审查，减少 500 错误。
• danpb：哇哦哦哦，终于启动了一个真正的虚拟机，使用了 nova + os-vif + openvswitch + privsep
• neiljerram：Neutron 路由网络规范今天合并了；感谢 Carl 以及所有贡献者！
• Sigmavirus24：Hacking 0.11.0 是该项目一年多以来的第一个发布版本。
• Stevemar：dtroyer 刚刚发布了 openstackclient 2.4.0 – 现在有了更多的网络命令 \o/
• odyssey4me：OpenStack-Ansible Mitaka 13.0.1 已发布！
• 全部

一个平台 – 容器/裸机？

• 来自非官方董事会会议 [1]，出现了一个关于如何真正支持容器和裸机，同时使用与虚拟机相同的 API 的有趣话题。
• 我们想强调 OpenStack 的优势在于能够提供虚拟机和裸机作为两种不同的资源，当出现“但云应该……”的观点时。
• 关于“支持容器”的讨论与 Nova 提供容器不同。
  • 而是与社区合作，使 OpenStack 成为运行 Kubernetes 和 Docker swarm 等的最佳场所。
• 我们希望支持裸机和容器，但我们支持的方式不同。
• 过去，曾考虑过为 Magnum 提供一个通用的计算 API，但人们理解该 API 将导致所有计算类型的最低公分母，以及极其复杂的接口。
  • 像 Trove 这样的项目希望提供这些计算选项，而无需在其自身项目中增加复杂性，可以使用 Nova 在部署虚拟机、裸机和容器（libvirt-lxc）的解决方案。
• Magnum 将在峰会上举行一次会议 [2]，讨论为 Kubernetes、Docker swarm 和 Mesos 构建一个通用抽象层是否有意义。
• 有人表达了原生 API 和 LCD API 可以共存的观点。
  • Trove 是一个不需要原生 API 提供的所有功能的服务的例子。
  • 将工作负载从虚拟机迁移到容器。
  • 支持应用程序的混合部署（虚拟机和容器）。
  • 将容器（在 Magnum bays 中）引入 Heat 模板，并启用容器与其他 OpenStack 资源之间的连接
  • 支持容器到 Horizon
  • 将容器指标发送到 Ceilometer
  • 跨容器解决方案的可移植体验。
  • 有些人只需要一个容器，并且不希望其他容器的复杂性（COEs、bays、baymodels 等）。
• 完整线程

Delimiter，配额管理库提案

• 目前，对于开发一个管理所有服务配额的服务存在相当多的反对意见。我们将讨论开发一个库，服务将使用它来管理自己的配额。
• 你不需要可序列化的隔离级别。只需使用带有重试策略的比较和更新。这将防止即使是多个写入者超额订阅任何资源，而无需隔离级别。
  • 库存表中的“generation”字段允许多个写入者确保数据的一致视图，而无需依赖关系数据库管理系统中的繁重的基于锁定的语义。
• 预留不属于配额库。
  • 预留是声明对某些资源进行一段时间占用的概念。
  • 配额检查是返回系统现在是否能够处理现在声明一组资源的请求。
• Delimiter 库的关键方面
  • 它是一个库，而不是一个服务。
  • 对资源消耗施加限制。
  • 将不负责速率限制。
  • 将不维护资源的数据。项目将负责保持/维护资源和资源消耗的数据。
  • 将不包含预留的概念。
  • 将从各自的项目获取项目配额。
  • 将考虑项目是扁平的还是嵌套的。
• Delimiter 将依赖于 generation-id 的概念来保证排序。Generation-id 提供了项目资源使用情况的某个时间点的视图。使用 delimiter 的项目需要在检查或消耗配额时提供此信息。目前 Nova [3] 具有 generation-id 的概念。
• 完整线程

Newton 发布管理沟通

• 负责 PTL 和联络人职位的志愿者有责任确保项目团队之间的沟通顺利进行。
• 电子邮件，用于公告和异步通信。
  • 发布团队将在 openstack-dev 邮件列表中使用“[release]”主题标签。
  • Doug Hellmann 将发送倒计时电子邮件，每周更新
    • 重点
    • 任务
    • 重要的即将到来的日期
  • 相应地配置您的邮件客户端，以便这些消息可见。
• IRC，用于时间敏感的交互。
  • 您应该设置一个 IRC bouncer，并在 freenode 的 #openstack-release 频道中提供。您绝对应该在截止日期期间（每个截止日期前一周）在那里。
• 书面文档，用于相对稳定的信息。
  • 发布团队已发布 Newton 周期的计划 [4]。
  • 如果您的项目有要添加到发布计划的独特内容，请向 openstack/release 存储库发送补丁。
• 请确保您的项目的发布联络人有时间并有能力处理管理您的发布所需的沟通。
• 我们的发布里程碑和截止日期是基于日期的，而不是基于功能的。日期过去后，里程碑也随之过去。如果你错过了，你就错过了。一些项目在 Mitaka 期间因为沟通不畅而遇到了问题。
• 完整线程

OpenStack 客户端缓慢

• 在分析 nova help 命令时，注意到 pkg_resource 模块及其对 pyparsing 的使用上花费了一些时间。我们能否通过不必为我们运行的每个命令启动新的 Python 解释器来避免启动延迟？
  • 在今天使用特定配置跟踪 Devstack 时，注意到 openstack 和 neutron 命令运行了 140 次。如果每次运行都有 1.5 秒的开销，我们可能会节省 3 分半钟的 Devstack 执行时间。
  • 作为概念验证，Daniel Berrange 创建了一个 openstack-server 命令，该命令侦听 unix socket 上的请求，然后调用 OpenStackShell.run 或 OpenStackComputeShell.main 或 NeutronShell.run。nova、neutron 和 openstack 命令将调用此 openstack-server 命令。
  • Devstack 结果，不使用此调整
    • real 21m34.050s
    • user 7m8.649s
    • sys 1m57.865s
  • Devstack 结果，使用此调整
    • real 17m47.059s
    • user 3m51.087s
    • sys 1m42.428s
• Dean Troyer 提出的一些说明，供有兴趣进一步调查此问题的人参考
  • OpenStack 客户端只有在实际需要进行 REST 调用时才会实例化任何项目客户端。
  • help 命令上的计时包括扫描所有入口点以生成命令列表。
  • --time 选项列出了所有通过我们的 TimingSession 对象正确进行的 REST 调用。除非库不使用给定的会话，否则应该都是。
  • 交互模式对于获取仅设置/拆卸过程的计时很有用，而无需实际运行命令。
• 完整线程

需要峰会讨论全球需求方面的输入

• 大型项目可互操作性会产生巨大的精力成本。使用容器、虚拟环境或不同主机进行服务隔离可以避免解决此问题。
• 例如，今天的 All-in-one 安装之所以受到支持，是因为开发环境使用 Devstack。
• 就像与向后兼容库和客户端的讨论一样，在同一主机上共存的 OpenStack 服务可能会共享相同的依赖项。今天，我们不能保证如果您将 Nova 升级到 Newton，它会升级与 Cinder 服务在 Mitaka 上使用的共享客户端/库。
• Devstack 使用虚拟环境几乎已经实现了这一点。由于运营商的反馈，此操作已停止。
• 传统的发行版依赖于社区在服务之间注意共享依赖项版本，以便可以使用 apt/yum 工具轻松安装 OpenStack。
  • 根据 2016 年 OpenStack 用户调查，56% 的部署使用“操作系统中的未修改软件包”。 [4]
• 其他发行版正在开始支持基于容器的软件包，其中一次只会有一个版本的库。
  • 无论如何，全球需求 [5] 将为我们提供一种鼓励依赖收敛的机制。
    • 限制运行 OpenStack 所需的知识。
    • 促进贡献者从一个代码库跳到另一个代码库。
    • 许可证检查的检查点。
    • 通过限制我们依赖的代码来减少整体安全风险。
  • 有些人认为这是退回到没有可靠的软件包管理的日子。例如，容器可能会滞后/缺少关键的安全补丁。
• 完整线程