计算管理器对象支持 (Juno 工作)¶

https://blueprints.launchpad.net/nova/+spec/compute-manager-objects-juno

此蓝图代表 Juno 中围绕将计算管理器（以及相关的模块，如 nova.compute.utils）迁移到使用对象而不是原始 conductor 方法的剩余工作。这很重要，因为对象提供了实际数据的版本控制，这支持我们的升级目标。

问题描述¶

nova 计算管理器仍然使用 conductor 和 compute RPC 方法发送未版本化的数据包，这在升级期间数据格式跨版本更改时会成为问题。这对于计算管理器尤其重要，因为在某些时候它可能会与较新的 conductor 和计算节点通信。在升级期间，预计会进行迁移和实时迁移操作，并且本质上会涉及运行不同版本代码的计算节点进行通信。

提议的变更¶

将计算管理器中原始 conductor 方法的使用迁移到对象。例如，考虑以下情况

service_ref = self.conductor_api.service_get_by_compute_host(
        context, self.host)
self.conductor_api.compute_node_delete(context, service_ref['compute_node'])

将变为

service = service_obj.Service.get_by_compute_host(context,
                                                  self.host)
service.compute_node.destroy()

备选方案¶

这是解决此问题的项目接受的方向。但是，替代方案包括

不解决问题并继续使用未版本化的数据
尝试在任何数据（包括嵌套的下游数据）发生更改时强制执行方法版本升级

数据模型影响¶

低级数据模型（即 SQLAlchemy 模型）不需要更改。但是，可以根据需要添加额外的更高级对象，以围绕低级模型提供版本化的包装。

REST API 影响¶

无。

安全影响¶

无。

通知影响¶

通常，将代码转换为使用对象不会影响通知。但是，在某些时候，通知的发出嵌入到对象方法中，以实现关于何时以及如何发送通知的更高一致性。在这项工作中没有预料到此类更改，但始终存在这种可能性。

其他最终用户影响¶

无。

性能影响¶

无。

其他部署者影响¶

迁移到对象增强了部署者逐步推出新代码的能力。然而，对于他们来说，这在很大程度上是透明的。

开发人员影响¶

这是正常的重构，因此影响很小。通常，基于对象代码更易于使用，因此从长远来看，这对开发人员来说是一项胜利。

实现¶

负责人¶

主要负责人: danms

工作项¶

check_can_live_migrate_destination
check_can_live_migrate_source
live_migration
_post_live_migration
_rollback_live_migration
_rollback_live_migration_at_destination
refresh_instance_security_rules
run_instance
detach_volume
compute/manager.py 中 instance[attr] 的剩余用法

依赖项¶

此蓝图与以下蓝图之间存在交叉依赖关系

https://blueprints.launchpad.net/nova/+spec/virt-objects-juno

在某些时候，virt 驱动程序需要修改以接受来自计算管理器的对象，然后才能完全转换管理器方法。

测试¶

通常，当这种情况发生时，单元测试需要进行最少的更改，具体取决于测试的结构。理想情况下，它们已经模拟了数据库调用，这意味着对对象的更改是透明的。实际上，这通常意味着对测试进行微调以返回完整的数据模型等。

文档影响¶

无。

计算管理器对象支持 (Juno 工作)