资源提供者创建时的生成版本

https://blueprints.launchpad.net/nova/+spec/generation-from-create-provider

为了促进资源提供者生成内部的封闭性,我们需要在创建提供者时返回(初始)生成版本。为了与其他 API 的一致性,我们将通过从 POST /resource_providers 返回整个资源提供者记录(包括生成版本)来实现这一点。

问题描述

bug 1746075 中所述,Placement API 消费者在处理新创建的资源提供者的初始生成版本时遇到了一些问题。Nova 报告客户端通过假设初始生成版本为 0 来处理它,这违反了 API 中生成版本的预期封闭性。

用例

作为 Placement API 的消费者,我希望能够获取新创建的提供者的初始生成版本值,同时保持其封闭性。

提议的变更

在一个新的微版本中,POST /resource_providers API 在成功时将返回 200,并带有表示资源提供者记录的有效负载。此有效负载将与当前微版本中通过 GET /resource_providers/{uuid} 返回的内容相同。

备选方案

  1. 紧接着 POST /resource_providers 之后,使用 POST 返回的 location header 中的 URI,使用 GET /resource_providers/{uuid}。这可以正常工作,但这是一个额外的 REST 调用。 建议的实现更方便。

  2. 假设提供者的初始生成版本为 0。虽然这恰好是正确的,但这种假设违反了 API 中生成版本的预期封闭性。

数据模型影响

REST API 影响

参见 建议的更改。输入规范除了 Openstack-API-Version header 之外是相同的。响应的差异是

  • 成功时,与返回 201 不同,新的微版本将响应 200

  • 成功时,与空主体不同,新的微版本将包含一个 JSON 有效负载,该有效负载表示新创建的资源提供者记录,格式与当前微版本中 GET /resource_providers/{uuid} 的响应相同。

安全影响

通知影响

其他最终用户影响

性能影响

其他部署者影响

开发人员影响

开发者可以方便地获取新创建的提供者的生成版本,而无需额外的 API 调用。

升级影响

直到他们的最小所需的 Placement 微版本至少是此规范生成的微版本,实现此功能的客户端在收到 406 时需要回退到 替代方案 中的一种。

实现

负责人

主要负责人

efried

工作项

  • nova.api.openstack.placement.handlers.resource_provider.create_resource_provider 中添加一个新的微版本处理程序,以返回 200 和提供者有效负载。

  • 更新 placement-api-ref。

依赖项

测试

将添加 Gabbits 以验证新的行为。

文档影响

参考资料

历史

修订版

发布名称

描述

Rocky

引入