POST 多重分配¶

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

随着迁移分配的计划，我们将通过类似于移动的操作声明的资源，由放置服务中的两个分配表示：一个由实例 UUID 标识，另一个由迁移 UUID 标识。当前可以通过向 Placement API 中的 /allocations/{consumer_uuid} 发送两个单独的 PUT 请求来完成。这可行，但存在竞态条件风险，并且需要两个步骤，而从逻辑上讲，我们希望调用者以一个步骤来思考。

问题描述¶

Placement 服务的主要目标之一是更准确地表示云中资源的实际使用情况，并利用这种提高的准确性来避免做出无法兑现的承诺（例如，“是的，我们有资源来执行此移动”），因为在承诺做出后但在操作完成之前，某些内容发生了变化。

在移动操作的情况下，如果我们尝试分两个步骤进行分配，就会出现 Placement 对现实的表示与我们期望不符的时间窗口（诚然通常很短，但延迟是不可预测的）。如果资源稀缺，其他内容可以在这个间隙中声明它们。

在移动的情况下，我们希望，例如，

通过删除实例声明并在一个请求中创建迁移声明来更改实例声明
在新目标位置上创建实例声明
如果构建成功，删除迁移声明

第一步是我们需要本文档中描述的解决方案。

用例¶

作为最终用户或操作员，我希望拥有可靠的移动操作，从而最有效地利用资源。

提议的变更¶

为了满足此要求，将在 Placement API 的 POST /allocations 处创建一个新的处理程序，它将接受多个消费者的分配请求集合，并在单个事务中保存所有请求，或者如果资源不可用或分配请求格式不正确，则使所有请求都失败。

请求体的各种选项的详细信息在下面的 REST API 影响中讨论。

备选方案¶

关于如何实现此功能的公开问题与现有的关于 /allocations/{consumer_uuid} 的 PUT 和 GET 的不对称错误相关。我们可以考虑对 POST 使用基于字典或列表的表示形式。有关示例，请参阅下面的 REST API 影响。

对于此用例，实际上没有合理的替代方案可以替代 POST /allocations。向相同的 URI 发送 PUT 违反了 HTTP 语义。这意味着“用我提供的内容替换系统中的所有分配”。使用不同的 URI 很难想象：PUT /allocations/{consumer_uuid},{migration_uuid},{some_uuid}。不用了。

数据模型影响¶

现有的数据库表已经足够。当前与 AllocationList` 对象关联的 project_id 和 user_id 属性需要移动到 Allocation 对象，以确保可以正确处理来自多个逻辑用户的分配集合。

REST API 影响¶

将在 POST /allocations 处创建一个新的处理程序，接受 application/json 格式的主体。成功后，它将返回 204 状态码和空主体。错误条件包括

400 Bad Request：当 JSON 主体不匹配模式时
400 Bad Request：当主体中命名的资源提供者或资源类
不存在时。
409 Conflict：当至少一个分配将违反库存
约束或可用容量时。
409 Conflict：当在分配过程中存在资源
提供者生成不匹配时（如果发生这种情况，客户端应重试）。通过主体中的错误文本，此 409 与前一个区分开来。

主体的格式如下，基于解决不对称 PUT 和 GET 错误以对齐于类似字典的格式

{
    "$INSTANCE-UUID": {
        "allocations": {
            "$TARGET_UUID": {
                "resources": {
                    "MEMORY_MB": 1024,
                    "VCPU": 2
                }
            },
            "$SHARED_DISK": {
                "resources": {
                    "DISK_GB": 5
                }
            }
        },
        project_id: "$PROJECT_ID",
        user_id: "$USER_ID"
    },
    "$MIGRATION_UUID": {
        "allocations": {
            "$SOURCE_UUID" {
                "MEMORY_MB": 1024,
                "VCPU": 2
            }
        },
        project_id: "$PROJECT_ID",
        user_id: "$USER_ID"
    }
}

$INSTANCE_UUID 和 $MIGRATION_UUID 是消费者 UUID。如果服务器上不存在任何消费者的分配，则将使用主体中 allocations 键中的值创建它们。如果已经存在分配，则将替换它们。 allocations 键的空值将意味着将删除该消费者的分配。

安全影响¶

无。

通知影响¶

无。

其他最终用户影响¶

如果 osc-placement 插件成为现实，则需要在那里添加此功能。

性能影响¶

无预期。

其他部署者影响¶

无。

开发人员影响¶

调度器报告客户端需要了解新的 URI 和微版本才能利用此功能。该客户端的用户，例如计算管理器需要更新。

实现¶

负责人¶

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

工作项¶

为新的主体表示形式编写 JSONschema
将 URI 和处理程序添加到 Placement
与 AllocationList 对象集成
为新的微版本添加 gabbi 测试
将 URI 的文档添加到 placement-api-ref

依赖项¶

与迁移分配相关

测试¶

Gabbi 测试可以涵盖通过 API 传递数据的大多数场景。重要的是，当报告客户端正在使用此代码时，确保功能测试正在验证分配最终是否正确。其中许多测试已经到位，这很好。

文档影响¶

placement-api-ref 需要更新以解释新的 URI。

参考资料¶

历史¶

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

POST 多个分配