OpenStack 开发人员邮件列表摘要 5 月 20-26 日

Mike Perez

2017 年 5 月 30 日

SuccessBot 说

clarkb 1 : infra 将 city cloud 添加到测试节点池。
pabelanger 2 : nodepool 启动了 opensuse-422-infracloud-chocolate-8977043。
全部： 3

etcd 3.x 作为基础服务

一个 devstack 审查 4 添加了一个新的 etcd3 服务。
两种启用 DLM 用例与 Tooz（用于基于事件的服务）的方法 5 6
完整线程： 7

我们是否要发布二进制容器镜像？

在论坛期间，讨论了各个团队构建或使用容器镜像之间的协作。
决定如何将来自各个团队的镜像发布到 docker hub 或其他容器注册表。
社区一直避免发布其他格式的二进制包，例如 deb 和 RPM。相反，我们已将此责任留给下游用户来构建生产包。
这需要更多地跟踪上游问题（错误、CVE 等），以确保镜像按需更新。
- 鉴于我们的安全和稳定团队资源，现在可能不是一个好主意。
Kolla 有兴趣为每日构建执行此操作。所有内容都已使用 ASL 许可，这不提供任何保证。
- 即使你将某项内容标记为不用于生产，人们仍然会使用它。以最近的用户调查中 DevStack 用于生产为例。
- Kolla 今天发布构建说明。手动地，每个版本他们都会提供构建的容器。
- 构建的容器将通过我们的 CI 网关运行，因此其他人不必拥有本地 CI 构建管道。
我们发布到 PyPi 的内容与此提案不同
- PyPi 发布的是源代码格式（sdist）和对开发人员友好的生产就绪格式（wheel）。
- 我们的大多数服务都没有打包和发布到 PyPi。这些库是为了方便我们在 CI 中使用它们。
- PyPi 中的工件包含对依赖项的引用，依赖项本身并没有构建到包中。
迭代 infra-spec 审查以发布到 DockerHub 已经开始 8
完整线程： 9

RFC 跨项目请求 ID 跟踪

在日志记录论坛会议中，讨论了操作员在服务器启动失败时重建流程所付出的努力。
- 在服务之间跳转时，请求 ID 会重置为新的内容。
- 能够在 elastic search 中查询服务之间通信中的相同请求 ID 将很有用。
担心信任线路上的请求 ID，因为它来自随机用户。
- 我们有一种新的“服务用户”概念，这些概念是具有更高权限的服务，我们使用它们来包装用户请求。
基本思想是
- 服务将可选地接收传入的 X-OpenStack-Request-ID，我们将强烈验证 req-$uuid 格式。
  - 他们也会继续生成一个。
  - 在构建上下文时，我们将检查是否涉及服务用户，如果未涉及，则将请求 ID 重置为本地生成的请求 ID。
  - 两个请求 ID 都将被记录。
- Python 客户端和调用者需要进行扩充，以便在请求中传递请求 ID。
- 服务器将选择以这种方式调用其他服务。
Oslo 规范已合并 10。
完整线程： 11

我们能停止全局需求更新吗（续）

Gnocchi 这次在 gate 上遇到了 Babel 的问题。Julien 计划在未来几个月内删除所有 oslo 依赖项。
Cotyledon 项目在某个峰会上被介绍为 oslo.service 的替代品，并摆脱 eventless。该库目前位于 telemetry 伞下。
- 该项目不在 oslo 下，以便鼓励更广泛的 python 生态系统采用和帮助维护它。
Octavia 也正在使用 Cotyledon。
完整线程： 12

修订后的 Postgresql 弃用补丁用于治理

在论坛会议中，我们同意以下内容
- 明确警告面向操作员的文档，Postresql 的支持不如 MySQL。
- 当然是调查从 Postgresql 迁移到 Gallera 以便为 OpenStack 产品的未来版本提供支持的过程。
- TC 治理补丁已更新 13。
当前卡点
- 重要的是操作员社区大部分人已经在一个阵营或另一个阵营。
- 未来的项目列出的是更重要，足以证明在这里进行严格权衡的项目。
- 即使提案的语气坚定，但它的一组具体行动是可逆的，并且不会承诺未来删除 Postgresql，也是可以的。
通过 SQLAlchemy 等抽象层所带来的困难
- OpenStack 服务在管理 DBMS 中发挥更积极的作用。
  - 请参阅以下关于我们数据库层主动或被动角色的摘要。
- 对于 Keystone 等服务，零停机时间升级的能力。
  - 使用代码扩展/收缩，并小心地在两个模式概念同时存在的情况下进行操作（例如 Nova 和 Neutron）。
  - 这不应该成为问题，因为我们使用 alembic 或 sqlalchemy-migrate 来抽象 ALTER TABLE 类型。
  - 使用服务器端触发器扩展/收缩以协调两个模式。这更困难，因为 SQLAlchemy 中不存在抽象层。可以构建一个特定于 OpenStack 的抽象层。
- 我们 API 中一致的 UTF-8 4 和 5 字节支持
  - Unicode 本身只需要 4 个字节，而这是目前任何数据库所支持的极限。这个问题在 Python 3 出现之前就已通过 SQLAlchemy 很好地解决。
- 新开发人员在尝试运行单元测试时需要编译 Postgresql 库。
  - 不关心 Postgresql 的新开发人员不必运行这些测试。
  - OpenStack 在 Kilo 中使用了 native python-MySQL 驱动程序，这需要编译。
  - 这是 OpenStack。我们是数千个 C 编译库和包的粘合剂。
- 区分大小写的排序规则一致性。
  - MySQL 默认设置为不区分大小写。
  - Postgresql 几乎不支持不区分大小写。
  - SQLAlchemy 支持 ilike() 等。
  - SQLAlchemy 中的字符串数据类型保证不区分大小写。
剩余的首要问题
- A1) 不要让用户在他们已经如此投入之后才发现他们走在一条不太常走的道路上而感到惊讶。用户可以选择道路，只要他们被告知他们需要更加自力更生。
- A2) 不要阻止 Keystone 等功能使用仅限 MySQL 的解决方案取得进展。
正交问题
- B1) Postgresql 是过去的人选择的，也许比我们意识到的还要多，这些是真正的用户，我们不想让他们陷入困境。彻底删除是不可能的。没有明确的路径，也没有关于谁在使用它的数据。
- B2) 上游代码没有被不可修复地更改（例如删除 SQLAlchemy 层），以至于不可能拥有替代数据库后端。
当前的提案 13 解决了 A1 和 B1。
完整线程： 14