按特征筛选资源提供者列表

https://blueprints.launchpad.net/nova/+spec/traits-on-list-resource-providers

部分原因是为了与 GET /allocation_candidates 保持持续的兼容性，部分原因是我们需要它来修复一个 bug，本规范建议向 GET /resource_providers placement API 添加 ?required=<trait_list> 查询参数过滤器。

问题描述

用例

作为使用 placement API 的 Nova 开发人员，我希望能够检索所有且仅检索与我的计算节点通过聚合关联的共享提供者（具有 MISC_SHARES_VIA_AGGREGATE 特征的提供者）。

提议的变更

在一个新的微版本中，允许 GET /resource_providers API 接受一个额外的查询参数 required，该参数接受逗号分隔的字符串特征名称列表。当指定时，API 结果将被过滤，仅包含标记了所有指定特征的资源提供者。

注意

与 resources 查询参数一样，required 的语义对于 GET /resource_providers 与 GET /allocation_candidates 不同。后者处理一组提供者，其中每个组必须集体满足过滤器；而前者将过滤器应用于每个提供者。

这除了（逻辑 AND）基于其他查询参数的任何过滤之外。

特征名称为空、在特征数据库中不存在或无效，将导致 400 错误。

备选方案

对于 用例 中的特定示例，首先检索与我的计算节点通过聚合关联的完整资源提供者列表；然后遍历每个提供者，调用 GET /resource_providers/{uuid}/traits API，查找结果中的 MISC_SHARES_VIA_AGGREGATE 特征，并仅保留存在该特征的提供者。这可能是我们需要回溯到 修复 提示此规范的 bug 所需的。

数据模型影响

无

REST API 影响

参见 提议的变更。该参数是可选的。它不会导致添加任何新的响应代码。

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

这应该通过将从 N+1 减少到 1 来提高性能，其中 N 是在没有新查询参数的情况下，通过初始调用 GET /resource_providers 返回的提供者数量。预计 placement 服务器上的额外处理将可以忽略不计，与这些额外 API 调用带来的开销相比。 （并且客户端本来也需要进行这种处理。）

其他部署者影响

无

开发人员影响

开发人员可以通过单个 API 调用获得经过特征过滤的资源提供者列表，从而更加方便。

升级影响

直到他们的最小必需 placement 微版本至少是此规范产生的微版本，实现此功能的客户端在收到 406 时需要调用 替代方案 中描述的备用代码。

实现

负责人

主要负责人

efried

工作项

  • 为 GET /resource_providers 的新微版本创建 JSON Schema。

  • 在 nova.api.openstack.placement.handlers.resource_provider.list_resource_providers 中添加一个新的微版本处理程序，以接受新的 required 参数并将其添加到 filters 中。

  • 调整 ResourceProviderList.get_all_by_filters 方法，以额外地根据指定的特征名称进行过滤。

  • 更新 placement-api-ref。

依赖项

无

测试

将添加 Gabbits 以验证查询参数。

文档影响

参考资料

历史

修订版

发布名称

描述

Rocky

引入