用 Pecan 替换自研 WSGI 层

https://blueprints.launchpad.net/neutron/+spec/wsgi-pecan-switch

本文档描述了一个计划，即用完全基于 Pecan 框架的解决方案 [1] 替换当前自研的 WSGI 框架，包括 REST 控制器。

本文档中讨论的规范可以使用 V3 插件规范，但不再假定依赖于该规范。有关更多详细信息，请参阅 [2]。

问题描述

本规范解决了由于 Neutron 到目前为止一直依赖并演进其自身框架来管理 Web 服务生命周期并将 API 操作分派到插件而产生的一些问题。

具体来说

  • API 资源定义使用字典完成，其中包含有关对象属性类型、默认值和属性验证的信息。这存在许多限制，尤其是在执行 API 资源的验证和序列化时，并且它还鼓励了一种行为，即一切都作为字典传递。

  • 当前的 API 扩展管理框架意味着扩展可以几乎随心所欲地操作 API - 甚至可以重新定义部分 API。

  • 存在基于 fork() 的自研代码，用于管理多个 API worker。虽然这通常不是问题，但它仍然是需要维护的大量代码。许多 REST 框架（如 Pecan）都内置了支持生成多个 API worker 的功能。

  • 由于 REST 控制器还需要处理诸如强制执行配额和授权 API 请求之类的任务，因此它们已成为重量级组件。

  • REST 层实际返回的响应当前在插件中构建，因为与插件之间没有面向对象的接口。实际上，REST 控制器将资源作为字典传递给插件，并期望从插件获得一个资源作为字典。它假定插件构建一个符合资源模型的字典（确保仅将有效属性返回给 API 消费者）。

  • 最重要的是，当前的 WSGI/REST 框架是 Neutron 代码库中一个相对较大的组件。切换到成熟的框架将使整个代码库更易于维护。

提议的变更

简而言之：用 Pecan 替换现有框架，删除当前代码，并确保操作员不受此更改的影响。

这意味着我们期望 Kilo 版本具有以下特性

  1. 所有 API 请求都将由 Pecan REST 控制器提供服务。这将影响树内属性扩展。实际上，这些扩展将被重构，因为它们当前使用与 attributes.py 中相同的基于字典的样式来定义它们处理的资源 [3]。因此，将有一个新的流程来将扩展添加到 Neutron API。此流程将在本蓝图的文档中记录。

  2. 服务启动将不再通过 Python PasteDeploy 进行，而是由 Pecan 管理。同样，多个 API worker 也将通过 Pecan 处理。

  3. Pecan REST 控制器将仅负责将响应序列化并将其反序列化为适当的传输对象，这些对象描述了 API 资源。在合并此处引用的 V3 插件层 [2] 之前，REST 层将继续负责授权和配额执行。请求验证将在 REST API 层中发生。目标是使用 JSON schema 指定约束。在撰写本文时，尚未分析是否可以使用 JSON schema 表达当前应用于 Neutron API 的所有验证约束。最终实现（不一定是第一次迭代）可能

    • 仅使用 JSON schema

    • 将验证逻辑嵌入到 API 对象中（参见 [2] 了解更多信息）

    • 使用 JSON schema 和自定义验证逻辑的混合，并可能将所有内容封装在 API 对象中。

  4. 另一方面，必须在将调用分派到插件层之前对请求进行身份验证。Pecan 钩子 [4] 将用于在适当的时间执行身份验证。

  5. 但是，Pecan 框架仅负责管理 REST API 服务器。因此，作为本蓝图的一部分，REST 和通过 AMQP 的 RPC 服务器将被拆分。此更改对部署者的潜在影响在相关部分中讨论。预计此拆分不会对操作员、开发人员或用户产生任何其他相关影响。API 服务器和 RPC 服务器将通过 RPC 进行通信，在必要时进行通信。在需要触发异步通知任务时，任何通知消息都将由 post api 调用钩子处理。通知系统将从 API 层的副作用转变为插件层的一部分。API 可以触发 RPC 通知或可能生成在 RPC/task flow worker 上执行的任务。

数据模型影响

预计不会更改数据模型。

REST API 影响

即使此补丁对 Neutron 管理层产生深远的影响，REST API 本身不会发生任何变化，并且将保留其在资源、可用操作、过滤、分页和排序方面的功能。

安全影响

处理 REST API 请求的框架的根本性变化始终具有潜在的安全影响。

在这种情况下，由于我们正在从自研框架转向已经在 OpenStack 项目中广泛采用的框架，因此整体安全级别应该会提高。

通知影响

REST API 层当前负责发送 Telemetry 服务所需的通知。随着这些更改，通知将不再在 REST API 层中处理，而是移动到插件接口中，如 [2] 中指定的。

其他最终用户影响

最终用户甚至不会注意到运行自研框架的服务器和切换到 Pecan 的服务器之间的区别。

性能影响

预计没有重大影响。但是，我们没有可用的测量数据来证明这一说法。

因此，应将性能测量作为本蓝图实施的一部分来完成，以确保切换到 Pecan 不会对应用程序性能产生负面影响。

为了这项工作，将使用 Rally 提供基准测试结果。如果认为其他工具（如 OsProfiler）有用，也将使用它们进行评估。

IPv6 影响

与 IPv6 相关的 API 和 IPAM 功能将保持不变。

其他部署者影响

我们预计部署者影响将是最小的。此更改从部署者角度引入的主要区别在于 HTTP 服务器将与 AMQP 服务器分离。

对于全新部署，这根本不是问题。它还将为部署者提供将 HTTP 和 AMQP 服务器部署在不同节点上的理想选择。

对于现有部署，更新应该平稳且透明。唯一的区别是，升级后将不再有单个 neutron 服务器服务，而是有两个 - 一个用于 REST API，一个用于通过 AMQP 的 RPC。

开发人员影响

新的扩展需要以不同的方式开发。这将在开发人员文档中进行全面记录。

社区影响

远离自研框架将使社区能够专门关注 Neutron 的业务逻辑。此外，Neutron 社区的成员也将被鼓励为 Pecan 做出贡献。

备选方案

已经考虑了其他解决方案，例如 Falcon [5] 和 WSME + Pecan [6]。但是，采用 Pecan 似乎最适合 Neutron。

邮件列表讨论 [7] 关于 REST API 框架已被用来提供一些指导。对于 WSME，即使它是一个有趣的解决方案，可以提高代码可维护性和简化开发过程，但在一些早期实验中，我们难以使其与当前的扩展模型一起工作。即使有人认为问题在于扩展模型，我们也无法将其推荐作为本蓝图的一部分。

实现

负责人

主要负责人

Kevin Benton (kevinbenton) Brandon Logan (blogan)

其他贡献者

Sean Collins (sccal68) [开发人员文档] Salvatore Orlando (salv-orlando) [储备开发人员] Mark McClain (markmcclain)

工作项

  1. 定义核心和扩展资源 Pecan 控制器的框架。

  2. 重新实现基本和扩展资源的控制器，特别注意正确处理“attribute”扩展。这项工作的可交付成果将是一个新的“基本控制器”，它将利用 [2] 中提出的 v3 插件接口。

  3. 将授权和配额执行插入到“插件管理”层中。

  4. 拆分通过 AMQP 的 RPC 服务器

  5. 重新定义单元测试以使用新框架

  6. 使用集成测试验证新解决方案，执行性能和可扩展性分析。

依赖项

虽然不是直接依赖项，但 V3 插件接口 [2] 在 Liberty 中再次提出时列出。

测试

一旦更改到位并与讨论的新的插件接口 [2] 集成，门控测试应像往常一样运行。我们预计此更改不会产生任何可能触发导致间歇性门控失败的竞争条件的影响。

另一方面，此更改将对单元测试产生重大影响。大多数单元测试都对 REST API 服务器进行练习，并且此更改将不可避免地破坏这些单元测试。因此，根据本提案，我们预计单元测试的“基本类”将发生重大变化，例如 [8]。

此外，作为本蓝图的一部分引入的新模块应进行彻底的单元测试，目标覆盖率在 90% 到 100% 之间。应使用 tox -ecover 验证测试覆盖率。

Tempest 测试

预计没有新的测试。

功能测试

即使 API 功能测试最终将成为 Neutron 功能测试套件的一部分，但这超出本规范的范围。

API 测试

请参阅上一节。

文档影响

由于本文档中讨论的规范更改了 Neutron 服务器的部署方式，因为 HTTP 服务器与通过 AMQP 的 RPC 服务器分离，因此需要在管理指南中对此进行适当记录。

用户文档

没有变化。

开发人员文档

应全面记录开发 Neutron 扩展的新流程。

还需要根据本蓝图所做的更改来更新 API 层的开发人员文档 [9]。

参考资料