启用 cell0 中实例的重建

https://blueprints.launchpad.net/nova/+spec/enable-rebuild-for-instances-in-cell0

本文档总结了启用由于资源不足而无法调度的实例重建所需的更改。

问题描述

目前，只要服务器之前已成功启动，就可以重建处于 ERROR 状态的服务器。但是，如果用户尝试重建一个从未启动过的实例，因为调度器由于资源不足而找不到有效的宿主机，则请求将以 InstanceInvalidState 类型的异常失败。我们不处理服务器由于超过最大构建重试次数而从未启动的情况。

用例

  1. 作为操作员，我希望能够在服务器由于资源不足而无法调度（例如，实例最终处于 PENDING 状态，如果已配置）后执行纠正操作。这些操作可以包括添加更多容量或释放已用资源。在执行这些操作之后，我希望能够重建失败的服务器。

    注意:: 将 PENDING 状态以及将其设置为实例状态，超出本文档的范围，因为它们正在由另一个更改[1]处理。

提议的变更

由于资源不足导致的调度失败，映射到 cell0 的实例的重建过程将如下所示

  1. nova-api 在识别到实例位于 cell0 后，应创建一个新的 BuildRequest 并更新实例映射。

  2. 此时，api 还应从 cell0 DB 中删除实例记录。如果这是软删除，那么在操作成功完成后，我们将在新 cell 的 DB 中得到一个实例记录，以及 cell0 中的一个相同实例记录（deleted=True）。更好的方法是，从 cell0 硬删除实例信息。在重建实例和从 cell0 删除它之前，用户可能会尝试更新它（例如，其元数据、标签等）。然后，我们可能会遇到竞争条件，并且这些更改无法传递到新的 cell。虽然这个窗口非常小，但我们必须在此处提及它。

  3. 然后，nova-api 应该向 conductor 的新方法 rebuild_instance_in_cell0 发出 RPC API 调用。这个新方法的目的几乎（如果不是完全）与现有的 schedule_and_build_instances 相同。因此，我们可以选择在内部调用它，或者提取其部分功能并重用它们。

  4. 最后，需要从 conductor 到所选 cell 的计算服务的 RPC API 调用。 rebuild_instance 方法尝试销毁现有实例，然后重新创建它。在这种情况下，由于实例位于 cell0，因此无需销毁和重新创建。因此，似乎调用现有的 build_and_run_instance 方法是合适的。

唯一的问题是，当实例在构建过程中失败时，其 network_info 字段为空。目前无法在尝试重建实例时恢复请求的网络。因此，应在构建服务器时存储 NetworkRequestList 对象。

为此

  1. 一个合理的更改是扩展 RequestSpec 对象以添加一个 requested_networks 字段，请求的网络将存储在该字段中。请注意，requested_networks 仅在实例在调度过程中失败并映射到 cell0 时存储在 RequestSpec 中。一旦重建过程开始并检索到请求的网络，新的字段将被设置为 None。

  2. 在构建服务器和创建请求规范时，我们应该将请求的网络列表添加到 RequestSpec 的 requested_networks 字段中。

备选方案

无。

数据模型影响

在 RequestSpec 对象中添加一个 requested_networks 字段，该字段将包含一个 NetworkRequestList 对象。由于 RequestSpec 作为 blob（mediumtext）存储在数据库中，因此不需要模式修改。

REST API 影响

需要一个新的 API 微版本。重建映射到 cell0 的实例对于旧的微版本将继续失败。

安全影响

无。

通知影响

无。

其他最终用户影响

用户将被允许重建由于资源不足而失败的实例。

性能影响

无。

其他部署者影响

无。

开发人员影响

无。

升级影响

无。

实现

负责人

主要负责人

<ttsiouts>

其他贡献者

<johnthetubaguy> <strigazi> <belmoreira>

工作项

参见 提议的变更。

依赖项

无。

测试

  1. 必须添加单元和功能测试来验证 cell0 中实例的重建。

文档影响

我们应该更新文档，说明允许重建从未启动过的实例。

参考资料

[1] 添加 PENDING 虚拟机状态

在都柏林 PTG 上讨论

历史

修订版

发布名称

描述

Rocky

引入

Stein

重新提出