提供 nova-manage 命令来刷新块设备映射的 connection_info¶
https://blueprints.launchpad.net/nova/+spec/nova-manage-refresh-connection-info
Nova 的块设备映射中存储的 Cinder 卷附件关联的 connection_info 经常会变得陈旧。 以前，操作员必须直接查询数据库才能了解 connection_info 的当前状态，并且只能迁移或搁置实例以强制刷新此信息。
本规范旨在概述一些基本的，并且可能可以向后移植的 nova-manage 命令，这些命令将允许操作员查看和刷新 Nova 中特定块设备映射的 connection_info。
问题描述¶
如上所述，给定卷附件的 connection_info 存储在 Nova 中附加卷关联的块设备映射记录中。 如果环境发生更改，此 connection_info 可能会随着时间的推移而变得陈旧，最常见的例子是在使用 Ceph 作为 Cinder 卷服务的后端存储时更改 MON IP 地址。
多年来，也出现过各种迁移回滚问题，其中与块设备映射关联的 connection_info 实际上指的是另一个计算主机使用的 connection_info。
在两种情况下，直到现在，强制刷新 connection_info 的唯一方法是通过另一个迁移或搁置/取消搁置，这在卷的初始断开连接期间也可能失败。
因此，为操作员提供一种可靠的方式来刷新此 connection_info 将非常有帮助。
用例¶
作为操作员，我希望查看与块设备映射关联的当前 connection_info。
作为操作员，我希望在不进行搁置和取消搁置的情况下，刷新附加到用户已停止实例的块设备映射的 connection_info。
提议的变更¶
引入一组可以向后移植的 nova-manage 命令来管理与给定卷附件关联的 connection_info。
注意
$bdm_uuid下面指的是块设备映射记录的 UUID在 Nova 中，而不是 Cinder 中卷附件的 UUID。 可以使用
openstack server volume list $instance_uuid命令（openstackclient >= 5.5.0）或nova volume-attachments $instance_uuidnovaclient 命令获取附加卷的块设备映射 UUID。
添加一个命令来显示给定块设备映射的 connection_info¶
$ nova-manage bdm show $bdm_uuid
此命令将简单地显示当前存储在 Nova 数据库中的卷附件的所有属性。
注意
这也应该在 os-volume_attachments API 的某个微版本中实现，但为了本规范，我们只关注上述可以向后移植的 nova-manage 命令。
添加一个命令来刷新给定块设备映射的 connection_info¶
$ nova-manage bdm refresh $bdm_uuid
此命令将刷新 Nova 中基于卷的块设备映射记录的 connection_info。
先决条件¶
块设备映射引用一个附加的卷。
块设备映射附加到的实例必须处于 STOPPED vm_state 状态。
托管实例的计算节点使用 libvirt virt 驱动程序。
当满足这些先决条件时，该命令将首先锁定实例，以确保不会接受任何用户请求，并可能与 connection_info 的刷新竞争。
然后，该命令将向托管实例的计算节点发出 RPC 调用 remove_volume_connection，使用 libvirt virt 驱动程序卷驱动程序中现有的逻辑从计算节点断开原始卷连接。
对 remove_volume_connection 的调用还将通过调用使用 cinderv2 附件流程附加的卷的 terminate_connection API，或删除使用 cinderv3 附件流程附加的卷的卷附件，从而通过 Cinder 从计算节点卸载卷。
注意
我们无法为 cinderv3 附件流程预先创建一个新的卷附件，因为提供的连接器将与现有的附件冲突，从而导致失败。 这与实时迁移的情况不同，在实时迁移的情况下，源连接器和目标连接器不同，允许我们在 Cinder 中同时拥有两个活动的卷附件。
一旦 RPC 调用返回，我们就会使用计算连接器创建一个新的 cinderv3 卷附件，并将生成的 attachment_id 和 connection_info 存储在 Nova 中的块设备映射记录中。
这具有将一些卷附件从 cinderv2 流程迁移到 cinderv3 流程的额外好处。 虽然需要超出本规范范围的更多工作才能将 Nova 中的每个卷附件迁移到较新的流程，但这至少是朝着这个方向迈出的一步。
最后，实例将被解锁，允许用户现在打开实例，从而使用新更新的 connection_info 将卷连接到计算节点。
注意
与前面的命令一样，这也应该在 os-volume_attachments API 的新微版本中实现，但同样，为了规范的目的，我们只关注上述可以向后移植的命令。
备选方案¶
继续只允许通过迁移或搁置实例来更新 connection_info。 这无法很好地扩展，并且通常会导致更多问题，尤其是在 connection_info 变得陈旧且过时的情况下。
数据模型影响¶
无。
REST API 影响¶
无。
安全影响¶
没有，所述附件的 connection_info 已经通过 Cinder 可供所述附件的所有者使用。 未来可以在 Cinder 中使用服务凭据在微版本中将此作为仅管理员 API，以便于传递敏感属性（如密码、令牌和密钥环），但目前，nova-manage 命令暴露我们数据库中存储的内容不应影响我们的安全模型。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
无。
其他部署者影响¶
无。
开发人员影响¶
无。
升级影响¶
无。
实现¶
负责人¶
- 主要负责人
lyarwood
其他贡献者
功能联络人¶
- 功能联络人
lyarwood
工作项¶
引入一个命令来显示块设备映射的属性，包括卷附件 ID 和 connection_info。
引入一个命令来刷新块设备映射的 connection_info。
依赖项¶
无
测试¶
将编写功能和单元测试来验证这些命令。 我们还可以包含集成测试，例如一些运行后 playbook 和运行，但这对于这些命令着陆来说不是必需的。
文档影响¶
与所有 nova-manage 命令一样，将编写详细的操作员文档，详细介绍命令。
参考资料¶
无
历史¶
发布名称 |
描述 |
|---|---|
Xena |
引入 |
