介绍待处理 VM 状态

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

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

问题描述

用例

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

如果后续操作的结果是

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

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

    注意

    重建 API 需要进行调整，以处理在构建过程中失败并映射到 cell0 的实例。 此更改不在此规范的范围内，并由另一个规范 [1] 处理。

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

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

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

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

提议的变更

  1. 在 InstanceState 对象中添加 PENDING 状态。

  2. 在 compute vm_states 中添加 PENDING 状态。

  3. 在 server ViewBuilder 中添加 PENDING 状态作为新的进度状态。

  4. 添加一个配置选项，默认在 DEFAULT 组中为 False，以启用在 NoValidHost 事件上使用 PENDING vm_state。

    CONF.use_pending_state

  5. 在 conductor manager 的 _bury_in_cell0 方法中添加以下代码，以确保仅当操作员选择并且调度器报告的故障为 NoValidHost 时，vm 才被设置为 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}

  6. 添加一个新的 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 [2]。

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

其他最终用户影响

从引入新的实例状态和之后的新的微版本，最终用户需要考虑到实例可能通过 PENDING 状态（这可能发生也可能不发生，具体取决于操作员选择配置云的方式）。

性能影响

无。

其他部署者影响

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

开发人员影响

无。

升级影响

无。

实现

负责人

主要负责人

<ttsiouts>

其他贡献者

<johnthetubaguy> <strigazi> <belmoreira>

工作项

参见 提议的变更。

依赖项

无。

测试

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

文档影响

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

  2. 更新允许的状态转换文档，以包括

    BUILD to PENDING
PENDING to BUILD
PENDING to ERROR

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

  4. 记录在新微版本之后，实例也可能通过 PENDING 状态，具体取决于操作员是否选择启用此状态。

参考资料

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

历史

修订

发布名称

描述

Rocky

引入

Stein

重新提出

Train

重新提出