如果未确定符合条件的候选人，技术委员会将任命 PTL [1]。
已任命的 PTL
- Robert Clark 被提名安全 PTL
- Serg Melikyan 被提名 Murano PTL
- Douglas Mendizabal 被提名 Barbican PTL
- Magnum PTL 选举在 Adrian Otto 和 Hongbin Lu 之间进行
MagnetoDB 正在被放弃，没有选择 PTL。相反，它将被加速从 OpenStack 官方项目列表中移除 [2]。

需要发布帮助 – 我们彼此不兼容

Robert Collins 指出，我们用于识别发布中不兼容组件的约束系统正在工作，但发布团队需要社区的帮助来修复现有的不兼容性，以便我们可以完成完整的 Liberty 发布。
存在的问题
- OpenStack 客户端无法创建镜像。
  - 修复已合并 [3]。

Semver 和依赖关系更改

Robert Collins 说，目前我们没有提供关于当项目的唯一更改是依赖关系更改并且发布了版本时会发生什么情况的指导。
- 目前发布团队将依赖关系更改视为“功能”而不是错误修复。（例如，如果之前的版本是 1.2.3，需求同步发生，下一个版本是 1.3.0。）
- 这背后的原因很复杂，需要一些指导来回答问题
  - 此需求更改是否会破坏 API？
  - 此需求更改是功能工作吗？
  - 此需求更改是错误修复吗？
- 所有这些问题都可能是真的。一些例子
  - 如果库 X 将库 Y 作为其 API 的一部分公开，并且库 Y 的依赖关系从 Y>=1 更改为 Y>=2。X 这样做是因为它需要 Y==2 的功能。
  - 库 Y 未在库 X 的 API 中公开，但是，X 的依赖关系更改会影响独立使用 Y 的用户。（忽略此处围绕 PIP 的复杂性。）
- 提议
  - 无 -> 一个需求 -> 主要版本更改
  - 1.x.y -> 2.0.0 -> 主要版本更改
  - 1.2.y -> 1.3.0 -> 次要版本更改
  - 1.2.3. -> 1.2.4 -> 补丁版本更改
- Thierry Carrez 同意最后两个提议。默认情况下进行主要版本升级似乎有些过头了。
- Doug Hellmann 提醒我们不能假设依赖关系本身使用 semver。我们需要一些除了版本号之外的东西来确定 API 是否实际上被破坏。
- 由于这个问题非常复杂，Doug 宁愿简化对需求更新的分析，直到我们更好地识别自己的 API 破坏性更改并区分功能和错误修复。这将使我们保持一致，即使不是 100% 正确。

应用 vulnerability:managed 标签的标准

漏洞管理流程几个月前被带到了大型帐篷 [4]。
最初我们列出了漏洞管理团队 (VMT) 跟踪漏洞的仓库。
- TC 决定将此从仓库更改为交付物，因为按仓库标签被认为不可取。
Jeremy Stanley 提供了交付物如何获得此标签的透明度
- 给定交付物中的所有仓库都必须符合条件。如果一个仓库不符合，那么在给定的交付物中它们都不符合。
- 联系人
  - 交付物必须有一个指定的联系人。
    - VMT 将与此联系人联系以处理报告。
  - 一组核心审查员应成为 <project>-corsec 团队的一部分，并将
    - 确认错误是否准确/适用。
    - 提供对附加到报告的补丁的预先批准。
- 交付物的 PTL 应同意充当（或委托）漏洞管理联络人，以供 VMT 升级。
- 交付物仓库中的错误跟踪器应配置为最初向 VMT 提供对私下报告的漏洞的访问权限。
  - VMT 将确定漏洞是否报告在正确的交付物上，并在可能的情况下进行重定向。
- 交付物仓库应经过第三方审查/审计，以查找明显的不安全设计或风险实施的迹象。
  - 这旨在减少 VMT 的工作量。
  - 尚未确定谁将执行此审查。也许是 OpenStack 安全项目团队？
此提案的审查已发布 [5]。

跨所有 API 实现一致的 SSL 终止代理支持

当调试一个错误 [6] 时，发现一个问题，即位于执行 SSL 终止的代理后面的 API 将不会生成正确的重定向（http 而不是 https）。
- 已经进行了审查 [7]，提供了一个配置选项 ‘secure_proxy_ssl_header’，允许 API 服务基于标头 X-Forwarded-Proto 检测 ssl 终止。
2014 年还有一个相同的错误 [8]。
- 几个项目应用了补丁来修复此问题，但并不一致
  - Glance 添加了 public_endpoint 配置
  - Cinder 添加了 public_endpoint 配置
  - Heat 添加了 secure_proxy_ssl_header 配置（通过 heat.api.openstack:sslmiddleware_filter）
  - Nova 添加了 secure_proxy_ssl_header 配置
  - Manila 添加了 secure_proxy_ssl_header 配置（通过 oslo_middleware.ssl:SSLMiddleware.factory）
  - Ironic 添加了 public_endpoint 配置
  - Keystone 添加了 secure_proxy_ssl_header 配置
Ben Nemec 评论说，在服务级别解决这个问题是错误的，因为这需要更改许多不同的 API 服务。相反，应该在将流量转换为 http 的代理中修复。
- Sean Dague 指出，这应该在服务目录中完成。服务发现是所有服务在相互通信时都应使用的基本功能。OpenStack 规范 [9] 试图解决这个问题
- Mathieu Gagné 指出这行不通。服务目录中存在“拆分视图”，其中内部管理节点具有特定的目录，而公共节点（供用户使用）具有不同的目录。
  - 建议使用 oslo 中间件 SSL 来支持 ‘secure_proxy_ssl_header’ 配置以解决问题，只需少量代码。
  - Sean 同意需要考虑拆分视图，但是，不应该让另一层工作决定服务目录是否是跟踪我们的服务 URL 的好方法。我们不应该推动一个 Keystone 是可选的模型。
  - Sean 指出，虽然 ‘secure_proxy_ssl_header’ 配置解决方案支持存在一个具有 SSL 终止的 HA 代理到 1 个 API 服务的案例，但它可能不适用于 1 个 API 服务到 N 个 HA 代理的案例
    - 客户端需要正确理解“Location:” 标头。
    - 像 request/phatomjs 这样的库可以遵循 REST 文档中提供的链接，并且它们是正确的。
    - 少数“不使用 keystone”作为选项的服务能够正常工作。
  - ZZelle 提到此解决方案在服务本身充当代理时不起作用（例如，nova image-list）。
  - 此解决方案在具有一个终止地址到多个后端服务器的 HA Proxy 案例中是否有效？
    - 是的，通过尊重由 HTTP 代理设置的标头 X-Forwarded-Host 和 X-Forwarded-Port，使 WSGI 应用程序不知道前面有一个请求。
Jamie Lennox 说，同样的话题作为 Devstack 补丁的障碍，以在 gate 中使用 HA Proxy 进行 TLS 测试。
- 更长期的解决方案，将服务过渡到使用相对链接。
  - 这是一个非常大的变化。我们一直返回绝对 URL，因此假设所有客户端代码都会使用相对代码是一个很大的假设。这绝对是一个主要版本。
Sean 同意，我们可以为 Mitaka 获得更好的东西，使用代理标头。如果清理服务目录的使用，我们可以完成剩余的边缘情况。