在 Cinder 中存储卷格式信息¶

https://blueprints.launchpad.net/cinder/+spec/add-support-store-volume-format-info

问题描述¶

目前，Cinder 中有几个基于文件系统的驱动程序依赖于自动检测格式。Cinder 不存储卷的实际格式，并假定所有卷都是“原始”格式。

当使用 glance cinder store，并将 nfs 作为 cinder 后端，并且要复制的文件是 qcow2 镜像时，会出现其中一个问题。在执行扩展操作时，qemu-img 使用 resize 命令，该命令通过读取写入卷的镜像的 qcow2 头来检测卷格式为 qcow2。这导致镜像创建失败。这是个问题，因为当前代码依赖于自动检测格式，如果用户将 qcow2 镜像写入卷中，驱动程序会认为它是一个 qcow2 卷（而不是存储在原始卷中的 qcow2 镜像），从而导致复杂情况。因此，我们需要存储格式信息，而不是自动检测。

提议的变更¶

“格式”信息将被添加到卷的“volume_admin_metadata”中。“格式”将仅由基于文件系统的驱动程序设置/更新，其他驱动程序将不包含此元数据。“格式”字段将在 FS 驱动程序创建卷时创建，并设置为驱动程序配置为使用的格式。“格式”信息将在连接信息字典的 attachment get API 中返回。在克隆卷时，此字段将在新卷的元数据中更新。对于现有卷，我们检查 admin_metadata 中是否存在格式，如果不存在，我们可以执行 qemu-img info 来获取格式，并将其存储在 admin_metadata 中。

备选方案¶

一些 fs 类型驱动程序使用“qemu-img info”命令来判断卷的格式。但是，这种自动检测方法有很多可能的错误/利用向量。因为如果“原始”卷的开头内容恰好是一个“qcow2”磁盘，自动检测方法会错误地将此卷判断为“qcow2”卷。这与 glance 在使用 cinder 作为存储时导致镜像创建操作失败的问题相同。

数据模型影响¶

对于基于文件系统的驱动程序的卷，将在 volume_admin_metadata 表中存在相关的记录。对于此记录，键列是“format”，值是 volume_admin_metadata 表中的卷格式。

REST API 影响¶

“格式”信息将在 attachment get API 中返回

/v3/{project_id}/attachments/{attachment_id}

{
    "attachment": {
        "id": "3b8b6631-1cf7-4fd7-9afb-c01e541a073c",
        ...
        "connection_info": {
            "format": "raw",
            ...
        }
    }
}

安全影响¶

实现了对 bug 1350504 的正确/完整修复。

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

无

其他部署者影响¶

修复了用户可以通过将 qcow2 头写入卷而导致卷无法操作的问题。

开发人员影响¶

无

实现¶

负责人¶

主要负责人: whoami-rajat

工作项¶

为了支持此功能，工作项目是

在 fs 类型驱动程序中创建或克隆卷时，将格式信息存储在 volume_admin_metadata 表中。
在附加卷上执行快照删除（blockRebase）操作时，修改卷格式。
在执行扩展操作时，传递格式信息。
在连接信息字典的 attachment get API 中返回格式字段。

依赖项¶

无

测试¶

文档影响¶

添加有关 fs 驱动程序中 attachment get API 中可见的格式字段的文档。

参考资料¶

无

在 Cinder 中存储卷格式信息