将 Glance 的多个存储中的卷复制到镜像¶
https://blueprints.launchpad.net/cinder/+spec/copy-image-in-multiple-stores
本规范建议在将卷上传到镜像 API 时，将基础镜像引用发送到 Glance。
问题描述¶
在 Train 版本中，Glance 增加了配置多个存储的能力 [1]。 这样，操作员可以配置一个或多个相同或不同类型的存储，并使用其中一个作为默认存储。 如果在上传镜像时未指定存储，则镜像将存储在默认存储中。
在 Train 版本中，我提出了一项规范 [2]，其中 Cinder 可以通过卷类型指定 Glance 存储。 在卷类型中指定的存储将通过 x-image-meta-store 标头传递给 Glance。 即使操作员在卷类型中指定了 Glance 存储标识符，它也只会允许将卷镜像上传到单个指定的存储，而不会允许镜像的共置。 此外，它依赖于操作员配置卷类型的 extra-specs 以定义首选的 Glance 存储；如果操作员未采取此步骤，所有上传都将转到默认的 Glance 存储。
用例¶
目前，如果云提供商决定升级其云到 Train 版本以使用 Glance 配置多个存储的能力，并且从卷创建的基础镜像驻留在 Glance 的多个存储中，那么如果操作员未在卷类型的 extra-specs 中定义 Glance 存储，则从卷创建的镜像将始终上传到默认存储，并且没有办法将这些镜像位复制/拷贝到上传了基础镜像的所有存储中。 因此，今天操作员需要执行许多手动步骤来复制/拷贝 Glance 存储上的镜像位，尽管使用了“enabled_backends”配置选项。 为此，他/她需要手动将新创建的镜像从卷复制到所有存储，并使用 Glance API 注册这些其他位置的 URL。
提议的变更¶
当从镜像创建卷时，Cinder 当前将 image_uuid 存储在 volume_image_metadata 中。 当请求 Cinder 上传卷到镜像时，Cinder 应该将 ‘image_uuid’ 作为标头 ‘x-openstack-base-image-ref’ 传递给 Glance，以便 Glance 可以识别原始镜像所在的存储。 Cinder 还在卷类型中存储此 Glance 存储信息 [2]，其中与卷类型关联的存储标识符将作为标头 ‘x-image-meta-store’ 传递给 Glance，以将从卷创建的镜像上传到该特定存储。
如果从镜像创建卷，并且 Cinder 传递了 ‘x-image-meta-store’ 和 ‘x-openstack-base-image-ref’ 标头，Glance 将忽略 ‘x-openstack-base-image-ref’ 标头，并将使用 ‘x-image-meta-store’ 标头中指定的 store_id。
如果卷不可启动，并且卷类型中可用存储信息，则 Glance 将使用与卷类型关联的存储来上传从卷创建的镜像。
如果卷不可启动，并且卷类型中不可用存储信息，则 Glance 将使用“默认存储”来上传从卷创建的镜像。
备选方案¶
继续使用卷类型传递存储信息 [2]。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
Active/Active HA 影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
whoami-rajat
- 其他贡献者
abhishek-kekane
工作项¶
将存储在 ‘volume_image_metadata’ 中的镜像 uuid 作为标头传递给 Glance
添加相关测试
依赖项¶
依赖于 ‘支持 Glance 多个存储’ 的实现 [2]。
测试¶
添加相关单元测试
添加相关功能测试
添加 tempest 测试
文档影响¶
操作员文档应根据规范实现进行更新。
