Placement 中分配的 GET 和 PUT 的对称性¶

https://blueprints.launchpad.net/nova/+spec/symmetric-allocations

当在 nova 端（最初在资源跟踪器中）添加对 placement 分配的支持时，GET 和 PUT 中使用的表示形式的格式发生了差异。GET 采用字典导向的风格，而 PUT 采用列表导向的风格。此后，这种差异造成了困惑。字典风格被认为更容易使用，因此将创建一个新的微版本来支持这种形式。

问题描述¶

《通用资源池》规范描述了 GET 和 PUT /allocations/{consumer_uuid} 的响应和请求主体中使用的表示形式。这些不仅不相同（通常是期望的），而且从根本上是不同的：一个是基于字典，另一个使用列表中的条目。

这是因为在添加对 GET 的支持时，在变更 I69fbc4e9834ec6dc80dacf43f8fd9dc6ec139006 中，它是为了满足调用者的特定需求而构建的，其中按键检查数据最有用。此后，这种格式被声明为最易于使用，并且发现检索分配、操作它们以及将其发送回去是相对常见的。因此，我们应该修复它。

最初，此问题在 bug 1708204 中注册，并且随着希望解决 post-allocations 蓝图的需求而变得更加相关，该蓝图表达了对使用基于字典的格式的偏好，并且我们应该保持一致性。

用例¶

作为 Placement API 的用户，我希望读取和写入的表示形式保持一致，并且格式化为最有效的使用方式。

提议的变更¶

将对 PUT /allocations/{consumer_uuid} 请求主体的 JSON 模式进行版本控制（在新的 Placement 服务微版本中），以期望输入的数据采用与从 GET /allocations/{consumer_uuid} 检索到的数据相同的形式。格式如下所示。

因为写入分配需要 project_id 和 user_id 信息，所以 GET /allocations/{consumer_uuid} 的响应主体将扩展为包含这些字段。

同样，因为对 GET /allocation_candidates 的响应包括一个 allocation_requests 属性，其中包含一系列 JSON 对象，这些对象旨在不透明地作为 PUT /allocations/{consumer_uuid} 中的主体发送，因此将在相同的微版本中更新该响应的格式以反映基于字典的格式。请参见下面的示例。

备选方案¶

主要的替代方案是不采取任何行动。

数据模型影响¶

无。

REST API 影响¶

将更新对 PUT /allocations/{consumer_uuid} 请求主体的现有 JSON 模式，以期望以下形式的数据

{
    "allocations": {
        "RP_UUID_1": {
            "generation": GENERATION,
            "resources": {
                "DISK_GB": 4,
                "VCPU": 2
            }
        },
        "RP_UUID_2": {
            "generation": GENERATION,
            "resources": {
                "DISK_GB": 6,
                "VCPU": 3
            }
       }
     },
     "project_id": "PROJECT_ID",
     "user_id": "USER_ID"
}

generation 是可选的，如果存在将被忽略。允许这样做是为了保持对称性。为了进一步保持对称性，对相同 URL 上的 GET 的响应将包括 project_id 和 user_id 字段。

将更新 GET /allocation_candidates 的响应主体，以便 allocation_requests 对象将从以下基于列表的格式（周围的 JSON，包括 provider summaries 已排除，有关完整的响应主体，请参见列出分配候选者文档）

"allocation_requests": [
    {
        "allocations": [
            {
                "resource_provider": {
                    "uuid": "RP_UUID_1"
                },
                "resources": {
                    "MEMORY_MB": 512
                }
            },
            {
                "resource_provider": {
                    "uuid": "RP_UUID_2"
                },
                "resources": {
                    "DISK_GB": 1024
                }
            }
        ]
    },
    {
        "allocations": [
            {
                "resource_provider": {
                    "uuid": "RP_UUID_3"
                },
                "resources": {
                    "MEMORY_MB": 512,
                    "DISK_GB": 1024
                }
            }
        ]
    }
],

更改为新的基于字典的格式

"allocation_requests": [
    {
        "allocations": {
            "RP_UUID_1": {
                "resources": {
                    "MEMORY_MB": 512
                }
            },
            "RP_UUID_2": {
                "resources": {
                    "DISK_GB": 1024
                }
            }
        }
    },
    {
        "allocations": {
            "RP_UUID_3": {
                "resources": {
                    "MEMORY_MB": 512,
                    "DISK_GB": 1024
                }
            }
        }
    }
],

安全影响¶

无。

通知影响¶

无。

其他最终用户影响¶

无。

性能影响¶

无。

其他部署者影响¶

无。

开发人员影响¶

开发人员现在可以通过指定适当的微版本，在将分配发送到 Placement 服务时选择格式。

在实现此规范期间，或者在人们认为值得这样做时，应该更新用于从调度器报告客户端发送分配的微版本。

实现¶

负责人¶

主要负责人: cdent
其他贡献者: 你

工作项¶

编写表示所需格式的 JSON 模式。
添加对新微版本的支持，该微版本将验证 PUT /allocations/{consumer_uuid} 主体是否符合该新模式。
修改 GET /allocations/{consumer_uuid} 以包含 project_id 和 user_id。
修改 GET /allocation_candidates 以发送基于字典的格式。
集成处理数据以构成对 AllocationList.create_all() 的调用。
添加 gabbi 测试以测试新的微版本。
添加 placement-api-ref 文档以说明新的微版本。

依赖项¶

无。

测试¶

应小心确保测试涵盖微版本处理的边界情况。

文档影响¶

主要的文档影响在于 placement api-ref，其中需要为 PUT /allocations/{consumer_uuid} 描述一个新的微版本。

参考资料¶

历史¶

修订版¶
发布名称	描述
Queens	引入

Placement 中分配的对称 GET 和 PUT