扩展 Vendor Passthru¶
https://blueprints.launchpad.net/ironic/+spec/extend-vendor-passthru
使 VendorPassthru 和 DriverVendorPassthru 更加一致，并扩展其功能以支持同步和异步运行 vendor 方法，以及除了 POST 之外的不同 HTTP 方法。
问题描述¶
VendorPassthru 和 DriverVendorPassthru 存在不一致之处。VendorPassthru 方法是异步的，而 DriverVendorPassthru 方法是同步的。
此外，目前每个驱动程序负责实现自己的方法来调用其 vendor 方法，导致大量代码重复，并且出现诸如为相同类型的错误引发不同异常等问题。 另外，有些驱动程序会记录 vendor 方法引发的错误，或者将非 Ironic 异常转换为 Ironic 异常，而有些则不会。
除此之外，这两个端点仅支持一种 HTTP 方法：POST。 扩展它以支持其他 HTTP 方法会很好，因为有些驱动程序可能希望使用它们。 一个例子是 iPXE 驱动程序，支持 GET 将是有益的，因为 iPXE 脚本可以请求 Ironic API 中的 GET，这将返回应启动的内核和 ramdisk，然后脚本可以从那里进行链式加载。
另一个问题是，目前 vendor 方法无法通过我们的 API 发现，没有办法知道驱动程序当前暴露了哪些方法。
提议的变更¶
第一个更改是提供一种通用的方法来运行 vendor 方法，该方法应负责记录并将异常转换为非 Ironic 异常的情况。 该蓝图希望通过创建装饰器来装饰 vendor 方法并用自定义代码包装它来处理这些问题。
第二部分将扩展新的装饰器以添加有关每个 vendor 方法的元数据，并能够创建一种通用的机制来调用这些方法。 希望在 Ironic 中暴露某些独特功能的 vendor 不应关心编写自定义代码来调用其函数作为实现 vendor 接口工作的一部分，他们应该只关心实现 vendor 方法本身。 为了这项工作，我们还需要区分 VendorPassthru 和 DriverVendorPassthru 方法，因此装饰器应分为两个，但它们都可以共享相同的代码库，更多的是每种类型的别名。
第三部分是使 VendorPassthru 和 DriverVendorPassthru 更加一致。 我们应该使其可配置，以便每种方法都可以配置是否应同步或异步运行，而不是让每个端点以不同的方式运行。 将添加一个标志到装饰器中以表达这一点。
第四点是允许 vendor 方法支持不同的 HTTP 方法。 由于这是一个 REST API，vendor 从能够暴露使用所有可用 HTTP 方法的方法中受益。 但是，我们应该告知 vendor，例如，与 BMC 通信的同步 GET 方法可能不是一个好主意，因为 BMC 容易出现故障并且请求可能需要很长时间才能完成，以免他们自食其果。 但对于 iPXE 驱动程序动态生成配置而言，这将是有益的。
一旦我们有了通用的机制来映射所有 vendor 方法（该提案的第二部分），我们就可以通过我们的 API 将它们暴露出来。 通过对 ../vendor_passhru/methods 端点发出 GET 请求，它将返回该驱动程序或节点的可用方法。 对于每种方法，它将包括描述、支持的 HTTP 方法以及它是同步还是异步操作。
另一个更改将包括一个关于如何编写 vendor 方法的教程，并提供诸如关于不要以同步方式与 BMC 通信的提示。
还将添加一个向后兼容层，这样我们就不会破坏仍然使用其 vendor 接口上的自定义 vendor_passthru() 和 driver_vendor_passthru() 的非树内驱动程序。 如果这些方法存在于 vendor 接口中，它们将像以前一样被调用。 如果不存在，我们将使用新的机制来调用 vendor 方法。
备选方案¶
修改 VendorInterface 基类中的 vendor_passthru() 和 driver_vendor_passthru() 以运行 vendor 方法，基本上替代了装饰器概念，这将影响向后兼容计划，该计划仍然需要 conductor 知道它应该如何调用该 vendor 方法，是启动工作线程（异步）还是直接调用它（同步）。
数据模型影响¶
无。
REST API 影响¶
/v1/nodes/<uuid>/vendor_passthru 和 /v1/drivers/<driver>/vendor_passthru 将支持除了 POST 之外的不同 HTTP 方法，方法列表为：GET、POST、PUT、PATCH 和 DELETE。
/v1/nodes/<uuid>/vendor_passthru 将继续为以异步模式运行的方法返回 HTTP 202（已接受），但也将为同步运行的方法返回 HTTP 200（确定）。
/v1/drivers/<driver>/vendor_passthru 将继续为以同步模式运行的方法返回 HTTP 200（确定），但也将为异步运行的方法返回 HTTP 202（已接受）。
GET /v1/nodes/<uuid>/vendor_passthru/methods 将返回该节点支持的 vendor 方法及其元数据的列表。
GET /v1/drivers/<driver>/vendor_passthru/methods 将返回该驱动程序支持的 vendor 方法及其元数据的列表。
注意：这两个端点已经支持返回错误 HTTP 代码，例如 HTTP 400（BadRequest）等。
RPC API 影响¶
一个新的参数
http_method将被添加到 RPC API 中的 vendor_passthru() 和 driver_vendor_passthru() 方法中。RPC API 中 vendor_passthru() 和 driver_vendor_passthru() 方法的返回值也将更改为包括 vendor 方法的调用模式（异步或同步），以便 API 部分可以确定在成功的情况下应返回什么 HTTP 代码。
将向 RPC API 添加两个新的 RPC 方法：get_vendor_routes(<node id>) 和 get_driver_routes(<driver name>)，它们将返回该特定节点或驱动程序的可用方法列表，并将被
ironic-api服务用于通过 REST API 暴露此信息。
驱动程序 API 影响¶
从 VendorInterface 中删除 vendor_passthru() 和 driver_vendor_passthru()。 在这些更改之前，每个驱动程序都必须实现自己的方法来调用其 vendor 方法，并且这是通过 VendorInterface 中的 vendor_passthru() 和 driver_vendor_passthru() 方法完成的。 这将被 ConductorManager 中的一个通用方法所取代。 这也允许我们测试驱动程序是否继续在 VendorInterface 中实现自定义 vendor_passthru() 或 driver_vendor_passthru() 方法，如果是，我们将调用它们以使其向后兼容。 使用向后兼容模式调用时，我们将记录警告，说明在 vendor 类中拥有自定义 vendor 方法已被弃用。
Nova 驱动程序影响¶
无。
安全影响¶
无。
其他最终用户影响¶
将在 python-ironicclient 中添加对调用 vendor 端点时使用不同 HTTP 方法的支持，因为今天它仅假设 POST。
可扩展性影响¶
无。
性能影响¶
无。
其他部署者影响¶
无。
开发人员影响¶
编写 vendor 方法将更容易和更灵活。
实现¶
负责人¶
- 主要负责人
lucasagomes
- 其他贡献者
sambetts
工作项¶
创建一个装饰器，该装饰器将负责记录和处理 vendor 方法中的异常。
扩展装饰器以向方法添加元数据，并能够创建一种通用的机制来调用它们，而无需 vendor 为此编写自定义代码。
添加对同步和异步运行 vendor 方法的支持。
添加对 vendor 端点上不同 HTTP 方法的支持。
编写一篇文档，解释如何编写 vendor 方法。
添加客户端支持，用于使用不同的 HTTP 方法调用 vendor 方法。
依赖项¶
无。
测试¶
单元测试
对 API 更改的 Tempest 测试
升级和向后兼容性¶
此更改将与现有客户端向后兼容，因此他们仍然可以运行其自定义 vendor_passthru() 和 driver_vendor_passthru() 方法。
文档影响¶
将添加一篇新文档，解释如何编写 vendor 方法。
更新 Ironic 文档，以说明在 vendor 类中编写自定义 vendor_passthru() 和 driver_vendor_passthru() 方法已被弃用，并且将在 Liberty 周期中删除。
参考资料¶
无。
