引入待处理 VM 状态¶

https://blueprints.launchpad.net/nova/+spec/introduce-pending-vm-state

此特性增加了对 PENDING 服务器状态的支持。当调度器确定对于给定的请求没有可用容量，并且实例即将路由到 cell0 时，如果操作员希望，服务器应该被设置为 PENDING 状态，而不是 ERROR 状态。这将允许后续操作对最终用户透明地执行。

问题描述¶

用例¶

作为操作员，我希望启用一个外部服务（对 Nova 而言），在服务器的构建请求因 NoValidHosts 而失败后立即触发，并尝试释放请求的资源。

如果后续操作的结果是

成功，外部服务将尝试重建实例

POST /servers/{server_id}/action
{
    "rebuild": {
        "description": null,
        "imageRef": {image_id}
    }
}

NOTE::
The rebuild api needs to be adapted to take care of instances that fail
while building and are mapped to cell0. This change is considered out
of scope for this spec and is being addressed by another spec [1]

失败，外部服务将把实例的状态设置为 ERROR（使用 reset-state）

POST /servers/{server_id}/action
{
    "os-resetState": {
        "state": "error"
    }
}

为了实现这一点，对用户而言透明地，实例不应该被设置为 ERROR 状态，而是新的 PENDING 状态。

我们需要在此澄清，对于所有其他 VM 状态，最终用户将能够删除设置为 PENDING 状态的实例。由于删除处于新状态的实例引起的后续操作失败，必须由外部服务处理。

提议的变更¶

在 InstanceState 对象中添加 PENDING 状态。
在 compute vm_states 中添加 PENDING 状态。
在 server ViewBuilder 中添加 PENDING 状态作为新的进度状态。
添加一个配置选项，在 DEFAULT 组中默认值为 False，以启用在 NoValidHost 事件上使用 PENDING vm_state
```
CONF.use_pending_state
```

在 conductor manager 的 _bury_in_cell0 方法中添加以下代码，以确保 vm 仅在操作员选择并且调度器报告的故障为 NoValidHost 时才被设置为 PENDING

verify = isinstance(exc, exception.NoValidHost)

if CONF.use_pending_state and verify:
    vm_state = vm_states.PENDING
else:
    vm_state = vm_states.ERROR

updates = {'vm_state': vm_state, 'task_state': None}

添加一个新的 API 微版本，并将 PENDING 状态映射到 ERROR，以供请求到之前的微版本使用。请参阅 REST API 影响。

备选方案¶

遵循 vendor data 示例，并在操作员启用时从 Nova Conductor 向外部服务执行异步 REST API 调用。但是，从 conductor 执行异步 REST API 调用可能会对性能产生影响。

数据模型影响¶

无。

REST API 影响¶

此更改需要一个新的 API 微版本。对于旧的微版本，PENDING 状态将被映射到 ERROR 状态。

设置为 PENDING 的服务器的示例响应是

GET /servers/detail (new microversion)
{
   "servers":[
      {
         ...: ...,
         "name": "test",
         "id":"2dd26c1e-bc6f-45f6-83b3-2cb72ea026eb",
         "OS-EXT-STS:vm_state":"pending",
         "status":"PENDING",
         ...: ...
      }
   ]
}

GET /servers/detail (previous microversions)
{
   "servers":[
      {
         ...: ...,
         "name": "test",
         "id":"2dd26c1e-bc6f-45f6-83b3-2cb72ea026eb",
         "OS-EXT-STS:vm_state":"error",
         "status":"ERROR",
         ...: ...
      }
   ]
}

安全影响¶

无。

通知影响¶

首先，必须在服务器设置为 PENDING 状态时通知外部第三方服务。为此，使用现有的版本化通知 instance.update。

对于第二部分，需要一个通知，以告知外部服务服务器的构建过程结果。计划使用此通知以启用外部 Reaper 服务，以了解请求的资源需要在哪里释放。

将现有的 select_destinations 通知从非版本化转换为版本化，不在此规范的范围内。有一个现有的更改尝试解决通知的转换，并且可以采用 [2]。

其他最终用户影响¶

如果操作员选择启用配置选项 CONF.use_pending_state，最终用户将拥有处于 PENDING 状态的服务器。

性能影响¶

无。

其他部署者影响¶

将有一个新的配置选项指定是否使用 PENDING 状态。似乎此选项最合适的位置是 DEFAULT 部分。

开发人员影响¶

无。

升级影响¶

无。

实现¶

负责人¶

主要负责人: <ttsiouts>
其他贡献者: <johnthetubaguy> <strigazi> <belmoreira>

工作项¶

参见提议的变更。

依赖项¶

无。

测试¶

更新现有的单元和功能测试应该足以验证新状态的使用。必须添加新的单元和功能测试来验证新的通知。

文档影响¶

新的配置选项以及 PENDING 状态的含义应该记录在案。

更新允许的状态转换文档，以包含

BUILD to PENDING
PENDING to BUILD
PENDING to ERROR

记录一旦实例被设置为 PENDING 状态，实例的生命周期管理责任就转移到外部服务。

参考资料¶

[1] 启用 cell0 中实例的重建: https://review.openstack.org/#/c/554218/
[2] WIP：转换 scheduler.select_destinations 通知: https://review.openstack.org/#/c/508506/

正如在 Dublin PTG 中讨论的那样：https://etherpad.openstack.org/p/nova-ptg-rocky L472

历史¶

修订版¶
发布名称	描述
Rocky	引入
Stein	重新提出

引入 Pending VM 状态