增强撤离¶
https://blueprints.launchpad.net/nova/+spec/robustify-evacuate
撤离功能允许部署者在计算主机长时间宕机时重新定位和重建实例。它通过在其他地方简单地重建实例来实现。当原始计算主机恢复启动时，一些启动逻辑会查看那些似乎已被重新定位的实例，并从本地机器删除它们。在实践中，这存在问题，因为我们几乎没有信息可以作为依据来决定销毁数据——这实际上是一种猜测。
本规范建议通过显式记录实例撤离事件来提高此过程的鲁棒性，以便恢复的主机能够清楚地指示它应该删除实例的本地副本。
问题描述¶
Nova 中的撤离清理逻辑会猜测是否应该销毁数据。它不应该猜测，因为很容易导致 Nova 猜测错误，从而导致数据丢失。
例如，现在如果你有一个基于 libvirt 的系统，意外的主机名更改将导致数据丢失。想象一下，一个部署者有一个 CPU 故障的计算节点。简单的解决方法是将磁盘交换到一台相同的机器并重新启动。如果新机器导致主机获得不同的主机名（因为它在网卡的 MAC 地址不同，或者在机架中的位置不同），一旦 nova-compute 启动，它将假定所有实例都已移动并销毁它们。
另一个例子是拥有多个 vcenter 的 vmware 部署者。在启动 vcenter03.foo.com 时，配置文件包含一个指向 nova-compute 的 vcenter02.foo.com 的错误。当 nova 启动时，它将假定所有实例都已撤离并销毁它们的所有数据（即使在共享存储上）。
用例¶
开发人员希望在其云中启用撤离功能，并希望 Nova 仅在数据已安全移动到另一台主机后才销毁数据。
项目优先级¶
鲁棒性？技术债务？
提议的变更¶
我建议我们让撤离代码使用现有的迁移数据结构来记录该操作。该结构包含一个带有时间戳的源主机和目标主机记录，并且当前为用户发起的迁移请求提供了一个小型状态机来确认或撤销。我们需要完全相同的东西，但用于撤离操作，这些操作在源主机恢复启动时通过销毁数据来确认。
当主机启动时，它应该
检查未确认的撤离迁移，其中它是源主机
如果仍然存在，则删除本地数据
将迁移标记为已完成
这意味着我们需要在当前的迁移对象中添加一个“类型”或“原因”字段，以便将用户/管理员发起的迁移记录与撤离发起的记录分开（在适当的时候）。
由于我们将迁移条目保存在数据库中，这变成了一种操作日志，包括计算节点在返回时清理的墓碑。即使在恢复开始之前有多次撤离，每个主机都可以根据记录做出关于该做什么的明智决定。
备选方案¶
另一种选择是像现在这样，即我们猜测是否需要根据实例的主机字段似乎已更改来删除内容。这意味着你可以通过更改你的 hypervisor 主机名来触发删除代码。
上述的一种变体是使用 virt 驱动程序附加到实例提供的全局唯一的 hypervisor 标识符。这就像主机字段一样，我们尝试根据当前和预期值来猜测是否应该删除某些内容。但是，这两种方法都存在问题，即它们基于环境数据进行猜测，而不是告诉我们已执行撤离的记录。
数据模型影响¶
这将重用我们现有的迁移数据结构，因此数据模型的影响将很小。我们需要添加至少一个字段来跟踪迁移的方法。这将是类似于“resize”、“migrate”或“evacuate”的内容。这将允许我们扩展迁移日志模型以用于实时迁移以及移动实例的任何其他方法，以便日志能够准确到足以做出正确的决策。
REST API 影响¶
由于我们将继续仅通过现有的 API 接口（由上述添加的类型或原因字段键入）向用户显示用户发起的迁移，因此对 REST API 没有影响。
如果希望向用户/管理员公开这些与撤离相关的迁移，我们可以扩展现有的 os-migrations API 或创建一个新的撤离专用接口。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
用户不会因为猜测而删除他们的数据。否则他们不会注意到这种变化。
性能影响¶
计算节点启动时，为了查找撤离记录，数据库流量会增加。由于我们已经查找所有实例，通常是毫无理由地查找，这实际上可以减少整体流量并提高启动性能。
其他部署者影响¶
对部署者没有实际影响，除了更安全地运行撤离恢复代码。
开发人员影响¶
无。
实现¶
负责人¶
- 主要负责人
danms
工作项¶
扩展现有的迁移对象以支持原因/类型字段
使当前的撤离代码在实例撤离时创建迁移记录
使计算节点启动代码在启动时使用并确认这些记录，而不是基于主机名进行猜测。
将 destroy_after_evacuate 解决方法配置选项标记为已弃用
依赖项¶
无。
测试¶
在 tempest 中测试起来很棘手，因为它实际上需要关闭正在运行的计算节点。因此，将使用功能测试来启动一个包含多个计算的合理完整的环境，以便测试该功能。
文档影响¶
预计对用户或部署者没有实际影响，因此预计没有文档更改。
