实例任务 - 简史与入门

注意

该规范已被 efried 放弃，原因是它自 2015 年以来一直停留在积压目录中。

这最初是一个关于如何向用户暴露错误的故事。

从很早的时候，如果不是从一开始，Nova API 就有了实例故障的概念。这是一个记录，包含了 Nova 在处理实例时发生的故障信息。它在发生故障时向用户传达信息非常有用，但它有两个主要缺点。首先是它只在实例处于 ERROR 状态时可见，其次是只有最新的故障可见。随着 API v2.1 的出现，这些问题可能会得到解决。

在 API v2.1 进展之前，Nova 中添加了两个东西，称为 instance-actions 和 instance-action-events，以解决实例故障的缺点。Instance-actions 是一个用户可见的 API 操作日志，记录了用户请求的操作及其成功或失败状态。Instance-action-events 是一个面向管理员的日志，详细记录了调用的计算方法和发生的任何堆栈跟踪。这使得暴露故障成为可能，而无需将实例设置为 ERROR 状态。它们最大的缺点是宣传不足，因此用户可能不知道要查看它们。

在此过程中，我们意识到在实例上显示大多数错误的概念存在缺陷，我们需要一种方法来表示实例上的任务以及任务相应的成功或失败。例如，重启实例这样的操作可能在影响实例的电源状态之前就失败了，并且实例本身并未受到影响。在这种情况下，我们希望表示重启失败了，而不需要认为实例有故障/错误，因为它仍在正常运行。这导致了一个想法，即从 API 的角度来看，我们希望一个动作是，或导致，一个具有关联状态的任务的创建，而不是对实例的 /actions 进行 POST 请求。然而，作为中间步骤，我们可以让该 POST 请求创建一个任务资源并返回一个链接。jaypipes 在 http://docs.oscomputevnext.apiary.io/#servertask 提供了一个关于这可能如何实现的提案。

除了对 API 的影响，引入任务概念到 Nova 还有其他原因，请记住任务可以意味着像重建这样的高级操作，或者完成重建所需的多个独立工作单元

  1. Nova 代码实现了实例的初步状态机，其逻辑分散在多个模块中。然而，状态机中是否存在死胡同或无法达到的状态并不总是很清楚。如果各种操作的逻辑可以整合到任务模块中，我们就可以更容易地为它们创建适当的状态机。

  2. 结合上述想法，任务应该是 Nova 内部变更的机制。目前，我们将实例发送到一个方法，如 rebuild()，该方法包含重建的逻辑。我设想的是通过 RPC 发送任务对象，并让它驱动实例上的状态变更。最终，conductor/compute 可以只有一个像 execute_task_on_instance(task, instance) 这样的方法。这有点不切实际，但这可以是总体的概念。

  3. 实例上的动作应该能够被停止和恢复。这对于能够重新启动服务很重要。如果任务的状态可以持久化，那么当服务重新启动时，它可以接管并恢复任务。这意味着任务应该具有幂等性，这不太可能，或者它们应该有检查点。

  4. 未来的一个想法是剥离 nova-compute，使其成为一个任务工作者，其中包含的逻辑非常少，主要负责从队列中拉取任务。这使我们更接近于这样一个境地：单个虚拟机监控程序可以运行多个 nova-compute，只是从多个 conductor 拉取工作。这样，nova-compute 就不会成为单点故障。这个想法尚未在社区内讨论，只是我考虑过的一个想法，并且应该完全超出本文的范围。但它是任务可能实现的事情类型的一个例子。

任务的早期工作集中在 API 层面引入这个概念。最初的想法是先确定接口，然后重构 Nova 内部以符合该概念。这种方法有其优点，但也可以采用不同的方式。重点可以从 Nova 内部开始，先建立好框架，然后在细节明确后将其暴露在 API 中。我看到先开发 API 的主要优势是我们可以重构 Nova 内部，而不会完全受限于 API 目前暴露的状态机。我看到先开发内部的主要优势是，我们目前必须猜测任务应该如何暴露以及它们应该包含哪些字段，但通过在 Nova 内部实现它们，这将会变得清晰。

TaskFlow 怎么样？TaskFlow 是所有这项工作中潜在的实现细节，但我认为现在谈论将其集成到 Nova 中还为时过早。在将 RPC cast/calls 的混乱和 Nova 内部的隐式状态机解开，并开始将其中一部分集中到 conductor 中之前，还有很多工作要做，TaskFlow 才能看起来很合适。我的建议是在 Nova 内部努力迭代出一个任务模型，如果解决方案开始看起来适合 TaskFlow，那么就可以进行讨论了。换句话说，我们不要为了适应 TaskFlow 而改变 Nova，而是如果 TaskFlow 适合 Nova，就使用它。

最后，通过在任务之上实现，实例故障和实例操作应被弃用。实例故障应该可以通过将最后失败的任务暴露为实例故障来实现。实例操作是任务列表的简化视图。但是每个 API 操作有一个实例操作，并且可能有多个任务，因此需要选择一个任务来作为实例操作暴露。

问题描述

无

用例

无

提议的变更

无

备选方案

无

数据模型影响

无

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

无

其他部署者影响

无

开发人员影响

无

实现

负责人

主要负责人

无

其他贡献者

alaski

工作项

无

依赖项

无

测试

无

文档影响

无

参考资料

[1] http://docs.oscomputevnext.apiary.io/#servertask

历史

Liberty 提供的可选部分，旨在每次更新规格说明时描述新的设计、API 或任何数据库模式更新。有助于读者了解随着时间推移发生的变化。

修订版

发布名称

描述

Liberty

引入

Train

已放弃