Nova-vm-state-management
- Launchpad 条目: 改进虚拟机状态管理以约束状态转换
- 创建时间: 2011年10月12日
- 贡献者: Phil Day (HP Cloud Services)
总结
此蓝图将约束有效的状态转换到有限的子集，并确保剩余的转换导致一致且确定的行为。
具体来说
- 限制每个状态下的有效操作（例如，只能恢复已暂停的实例）
- 对状态序列进行一些小的更改，以提高上述功能的鲁棒性
- 确保长时间运行的操作检查当前状态，而不是假设状态未更改
原理
当前对有效状态转换的检查仅限于少数情况，导致出现多种非确定性行为的机会。 此外，某些长时间运行的任务可能导致奇怪的行为——例如，处于构建状态的虚拟机可能在镜像下载上花费很长时间，被终止，并且在镜像下载完成后继续启动虚拟机。
设计
虚拟机状态记录在三个实例属性中
"power_state" 由 hypervisor 的 "vm_state" 派生，通常由 Nova 代码在主要操作的开始和结束时更改 "task_state" 由 Nova 代码更改，以反映操作内的临时步骤
例如，以下显示了在创建操作期间如何更新这些状态值
| 节点 | power_state | vm_state |
| API | Building | |
| 调度器 | Building | |
| 计算 | Building | |
| Building | ||
| Building | ||
| Running | 活跃 |
完整的状态转换集将被映射出来并提供给文档团队。 从已经映射的那些，我们可以得出以下观察结果
- 大多数操作在早期设置 vm_state 和 task_state（在 compute/api.py 中），因此可以通过 task_state != None 确定正在进行中的任务
- 大多数操作在完成时清除 task_state，因此可以通过 vm_state 和 task_state = None 的组合来检查许多操作
- 始终需要至少保留一个有效操作（终止）
- 长时间运行的操作（例如镜像下载）应定期更新 task_state，以便用户可以知道正在取得进展
- 长时间运行的操作应检查并遵守状态更改（特别是已终止）
- 报告的状态应该是 vm_state 和 task_state 的组合
有效的转换的初始提议如下
| vm_state | task_state |
| !=None | |
| 活跃 | Resize_verify |
| 活跃 | 无 |
| Building | |
| ReBuilding | |
| Paused | |
| Suspended | |
| Rescued | |
| Deleted | |
| Stopped | |
| Migrating | |
| Resizing | |
| 错误 |
UI 变更
UI 不需要任何更改。
代码变更
对有效操作的检查将作为装饰器实现，例如
@check_vm_state("delete")
@scheduler_api.reroute_compute("delete")
def delete(self, context, instance_id):
"""Terminate an instance.""“
可能需要进行其他更改以确保 vm_state 和 task_state 设置一致（例如，task_state 在 Rebuild 期间当前会短暂变为 None，并且 live_migration 根本不更新状态。）
迁移
待定
测试/演示计划
待定
