Placement Forbidden Traits

https://blueprints.launchpad.net/nova/+spec/placement-forbidden-traits

我们已经探讨了需要对 Placement API 进行的各种查询，以检索资源提供者和分配候选者。已知能够表达“不具有特性 X、Y 和 Z”是有价值的。

因此，我们决定添加对附加查询语法的支持（如下所述），该语法将允许对 GET /resource_providers 和 GET /allocation_candidates 进行此类查询。

问题描述

特性可用于表明资源提供者在某种程度上是特殊的。在这种情况下，能够说“不要将这个特殊的东西用于这个非特殊的工作负载”是有用的。这允许保留特殊的资源。为了使 Nova 调度器等客户端表达此要求，Placement API 需要附加查询语法。

即使使用案例（如下所示）可以通过其他工具解决，这也被认为是在 API 中一种常用的表达方式。

用例

作为裸机服务的运营商，我希望保留我的昂贵 GPU 加载硬件，供付费比特币矿工使用，并且更愿意以积极的方式向我的硬件添加特性。也就是说，我想用 CUSTOM_MASSIVE_GPU 对硬件进行特性标记，而无需将 CUSTOM_NOT_MASSIVE_GPU 放在其他所有硬件上。相反，flavor 和其他形式的工作负载请求能够表达 NOT CUSTOM_MASSIVE_GPU。

类似地，一些运营商、部署者和工具制作者希望能够将资源提供者树的某个分支标记为表明该分支属于某个组或目的，然后能够表达“不是该组”。

提议的变更

调整 required 参数的处理方式，以便可以将特性表示为需要存在或需要不存在。需要不存在的特性以前缀 ‘!’ 开头。在以下示例中，我们需要 STORAGE_DISK_SSD 并且不需要 CUSTOM_GOLDEN_RAID

GET /resource_providers?resources=DISK_GB&required=STORAGE_DISK_SSD,!CUSTOM_GOLDEN_RAID

这种语法具有不需要新查询参数的优点，这可能是一件好事。然而，它也有可能被认为编码过多且缺乏可见性的缺点。然而，‘!’ 经常被理解为“非”。

更多细节如下。

注意

虽然本规范没有列举 nova-scheduler 处理 flavor extra specs 或 image metadata 以传递非必需特性所需的任何更改，但我们计划该格式将镜像用于必需特性的格式，并且为 trait:$TRAIT_NAME=forbidden。

备选方案

此更改的语法很容易引起争论，因此，以下替代方案列表远非完整，但举例说明如下

添加一个新的查询参数，forbidden，它是 required 的相反参数，并且具有相同的语法。它的意思是“此处列出的特性不应出现在结果中”。

这种格式对于现有用户来说可能更容易管理和推理，因为 flavor extra specs 中的现有语法如下所示

"trait:$TRAIT_NAME": "required"

这表明 forbidden 可以很好地工作为

"trait:$TRAIT_NAME": "forbidden"

是否应在 placement 端反映该语法尚不清楚。本规范的作者认为，对同一类型的事物使用两个不同的查询参数会令人困惑，但当然可以理解这种替代方案也可以很好地工作，而且感觉通常不足以证明语法。

数据模型影响

数据模型本身不需要更改，但是需要更改数据查询以排除具有必须不存在的特性的资源提供者。

REST API 影响

将创建一个新的微版本，该版本将更新 GET /allocation_candidates 和 GET /resource_providers 上 required 参数的验证，以接受 ! 作为列出的特性的前缀，以表达该前缀特性需要在结果中不存在。

然后，这些被禁止的特性将作为必需的传递给 ResourceProviderList.get_all_by_filters 或 AllocationCandidates.get_by_requests 方法。

如果 required 参数中列出的特性与在 required 参数中列出的特性重复，并且该特性以前缀 ! 开头，则是一个错误，并将导致 400 Bad Request 响应。不允许在 ! 和特性之间有空格。允许在 ! 和特性短语前后有空格，并将删除这些空格。

格式错误的特性将导致 400 Bad Request 响应（这种情况已经存在）。

如果选择替代格式，forbidden 的验证（以及相关的响应代码）将与 required 相同。

安全影响

N/A

通知影响

N/A

其他最终用户影响

N/A

性能影响

对数据库的查询将增加适度的复杂性，但现有的表索引应该能够很好地处理它。

其他部署者影响

N/A

开发人员影响

Placement 的客户端（例如 nova-scheduler）的开发人员需要了解新的语法。

升级影响

N/A

实现

负责人

主要负责人

cdent

其他贡献者

efried

工作项

  • 更新 ResourceProviderList.get_all_by_filters 和 AllocationCandidates.get_by_requests 方法，以更改数据库查询，以过滤掉“不是此特性”。这项工作可以在与 API 更改分开且先于 API 更改的补丁集中完成。

  • 在一个新的微版本中更新 placement API 处理程序，用于 GET /resource_providers 和 GET /allocation_candidates，以将负特性传递给上述方法，包括输入验证调整。

  • 添加对修改后的数据库查询的功能测试。

  • 添加 gabbi 测试，以表达新的查询，包括成功的查询和应该导致 400 响应的查询。

  • API 更改的发布说明。

  • 更新微版本文档以指示新版本。

  • 更新 placement-api-ref 以显示新的查询处理方式。

依赖项

N/A

测试

这里需要两层测试

  • 功能测试，以确认数据库更改正确。

  • Gabbi 测试，以确认 API 的行为。

文档影响

三个文档更改领域

参考资料

历史

修订版

发布名称

描述

Rocky

引入