嵌套资源提供者 - 分配候选¶
https://blueprints.launchpad.net/nova/+spec/nested-resource-providers-allocation-candidates
嵌套资源提供者功能已在 Queens 和 Pike 版本中添加到 nova 和 placement 中，但是仍有许多功能需要完善才能使该特性完全可用。其中之一是在 placement 服务中 GET /allocation_candidates HTTP 端点返回的分配请求中完全集成嵌套资源提供者。
问题描述¶
通过 update_provider_tree 工作，资源跟踪器和 virt 驱动程序现在能够构建一个嵌套资源提供者的树，每个提供者都装饰有各种 traits 并包含各种资源类的库存记录。
虽然这对于正确表示子提供者与父提供者的层次关系至关重要，但该层次结构尚未用于计算在预过滤计算主机期间返回给 nova 调度器的分配请求集合。
placement 服务需要考虑提供者在树中的成员关系，以确定提供者是否可以满足特定请求中的资源。
考虑以下安排，一个计算节点具有一些 VCPU 和 MEMORY_MB 库存，以及两个 SR-IOV 物理功能，具有 SR-IOV 虚拟功能的库存。只有其中一个物理功能装饰了代表不同类型卸载的 trait
compute node -- VCPU: 16, MEMORY_MB: 16384
/ \
/ \
NUMA NODE 0 NUMA NODE 1
| |
| |
SRIOV_NET_VF:4 -- PF 0 PF 1 -- SRIOV_NET_VF:4
HW_NIC_OFFLOAD_GRO
如果我们请求 2 个 VCPU 和 1 个 SRIOV_NET_VF 资源，我们期望得到 2 个分配请求，每个分配请求包含计算节点资源提供者用于 VCPU 资源，以及用于 SRIOV_NET_VF 资源的一个物理功能资源提供者。
然而，目前，我们将从 GET /allocation_candidates 获得 0 个结果。 同样，如果我们请求 2 个 VCPU 和 1 个 SRIOV_NET_VF 以及 HW_NIC_OFFLOAD_GRO 作为必需的 trait，我们期望得到 1 个分配请求，其中包含具有所需 trait 的 PF。 但是，我们目前得到 0 个结果，因为分配候选的计算方式“不了解嵌套”。
用例¶
无
提议的变更¶
更新 AllocationCandidates.get_by_requests() 方法，使其理解当存在提供者树时，资源可以由子提供者提供。 在评估必需的 traits 时，placement 服务必须确保 traits 与实际提供满足分配请求的库存的提供者相关联。
具体来说，使用 问题描述 中描述的主机，
GET /allocation_candidates?resources=VCPU:2,SRIOV_NET_VF=1
将提供以下结果
{
"allocation_requests": [
{
"allocations": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"VCPU": 2
},
},
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"SRIOV_NET_VF": 1
},
},
},
},
{
"allocations": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"VCPU": 2
},
},
"99c09379-6e52-4ef8-9a95-b9ce6f68452e": {
"resources": {
"SRIOV_NET_VF": 1
},
},
},
},
],
"provider_summaries": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"VCPU": {
"used": 0,
"capacity": 16
},
"traits": []
},
},
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"SRIOV_NET_VF": {
"used": 0,
"capacity": 4
},
"traits": []
},
},
"99c09379-6e52-4ef8-9a95-b9ce6f68452e": {
"resources": {
"SRIOV_NET_VF": {
"used": 0,
"capacity": 4
},
},
"traits": [
"HW_NIC_OFFLOAD_GRO"
]
},
},
}
请注意，在 provider_summaries 中，我们将仅显示位于 allocation_requests 中的资源提供者。
我们还希望调整 placement 服务，以便在 provider_summaries 中返回特定提供者树中与搜索条件匹配的所有提供者。 这由另一个 spec 顺序启用，Return resources of entire trees in Placement。
备选方案¶
无
数据模型影响¶
无
REST API 影响¶
引入一个新的微版本来指示提供者树现在在 GET /allocation_candidates 的返回中得到正确处理。
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
当存在提供者树时，评估分配候选将会更慢。 别无选择。
其他部署者影响¶
无
开发人员影响¶
无
升级影响¶
无
实现¶
负责人¶
- 主要负责人
jaypipes
工作项¶
添加一个函数来检索满足一组请求资源量和所需 traits 的提供者树
将该函数集成到
AllocationCandidates.get_by_requests()方法中，并添加一个微版本来指示新的行为
依赖项¶
无
测试¶
需要大量的函数测试来测试各种级别的嵌套
文档影响¶
当系统中存在嵌套资源提供者时，在评估资源和 traits 的请求时，placement 服务的行为应该非常明确。
