RelatedImages

• Launchpad Entry: NovaSpec:related-images
• Created: RickHarris
• 贡献者:

总结

在 Nova 和 Glance 中，目前没有机制来关联实例和镜像。这意味着，现在我们无法查询特定客户的镜像列表，并且在编写备份调度器时，我们无法根据特定实例查询镜像列表。

本提案旨在添加一种新机制，允许 OpenStack 部署将镜像与实例关联，而不会在 Glance 和 Nova 之间创建不必要的耦合。此外，由于并非所有 OpenStack 部署都希望维护实例和镜像的映射，因此该蓝图将此功能引入为可以在 Nova 和 Glance 中配置的选项。

发布说明

• 镜像列表现在仅显示可供给定客户使用的镜像
• 快照现在与创建它们的实例相关联

用户故事

• Alice 使用 OpenStack API 创建快照，当她检索可用镜像列表时，该镜像应该包含在内，但不包括其他客户的镜像。
• 备份调度器启动实例 123 的夜间备份。备份调度器应该能够查询与实例 123 关联的备份。

前提条件

松散耦合

我们希望在 Nova 和 Glance 之间保持松散耦合；Glance 默认情况下不应了解 Nova；并且 Nova 默认情况下不应了解 Glance。

Nova 与 Glance 的多对多关系

Glance 和 Nova 应该具有两者之间的多对多关系；即，一个 Nova 可以与多个 Glance 实例通信，并且一个 Glance 实例可以为多个 Nova 实例提供服务。（目前 Nova 仅支持一个 Glance 实例；然而，这仅仅是为了引导 Nova/Glance 集成而施加的一种便利性，而不是核心架构的一部分。随着 Nova 和 Glance 的成熟，我们预计会删除 Nova 中的此限制。）

设计

此设计的核心主题是，并非所有 OpenStack 安装都需要了解实例的镜像，因此应该将其视为可选功能。

为了实现这一点，我们建议对 Nova 进行一些小的更改，以及对 Glance 进行一些添加。

Glance 的添加

我们当前在 Glance 中使用 WSGI 堆栈。我们建议添加一个 WSGI 中间件层，将了解实例的镜像（也称为 related-images）添加到核心 glance-registry 中。

InstanceAwareMiddleware 层将拦截请求，解析任何与实例相关的元数据，将其存储在单独的表中（甚至在单独的系统中，如果需要），删除实例元数据，然后将请求传递到核心 Glance registry 组件。

Nova 的修改

如假设部分所述，一个要求是 Glance 能够支持多个 Nova 安装。由于 Nova 中的 instance_ids 只是顺序 ID，而不是全局唯一的，我们需要为 Nova 安装创建一个全局唯一标识符，我们可以将其与实例元数据一起存储。这个 (nova_installation_uuid, instance_id) 元组将是全局唯一的。

为了将此 (nova-installation_uuid, instance_id) 元组传递给 Glance，而无需要求所有 OpenStack 部署都使用此配置，我们建议使用一个新的可选 ImageService，该服务在请求中提供此实例元数据。为了便于本文档的说明（我们保留在实施期间更改实际名称的权利），我们可以将其称为 InstanceAwareGlanceImageService。

InstanceAwareGlanceImageService 只是围绕现有的 GlanceImageService 的一个薄包装器，它传递 instance-identification 元组。

实现

Glance 实现

实施需要添加了解实例的 WSGI 中间件。这将保存在一个可选的 middlewares 目录中。

此 WSGI 中间件将使用实例-镜像映射表。对于第一次尝试，我们建议此表存在于 Glance 数据库中。但是，由于架构明确指出此表是可选的，因此将来我们可以将此表移至单独的系统。

Nova 实现

我们需要添加 Nova 安装的全局唯一标识符。由于 related-image BP 将是唯一使用它的功能，因此现在标识符可以可选。但是，随着时间的推移，我们预计此标识符对于其他功能将是必要的，因此我们建议所有部署都生成一个。

Nova 标识符只是在 Nova 首次部署时生成的 UUID。该标识符将作为 gflag 存储。

为了便于生成此 UUID，我们可以将一个辅助工具添加到 nova-manage，该工具生成此 UUID。例如

 $ nova-manage generate-installation-uuid
 --nova-installation-uuid=ABCD-1234-ABCD-1234

我们可以从 GlanceImageService 派生 InstanceAwareGlanceImageService，并在请求中简单地填充 (nova_installation_uuid, instance_id) 元组。

UI 变更

无

代码变更

如实施中所述。

迁移

无

测试/演示计划

最终目标是支持 OpenStack API 镜像与实例关联的概念。为了测试这一点，我们可以

1. 使用单元测试，其中我们 stubout 一个 InstanceAwareGlanceImageService。然后，我们可以在客户上下文中对 OpenStack API 进行镜像列表调用，并且应该只看到客户的镜像（加上公共镜像）。

2. 我们还需要功能测试来确保此过程端到端工作。由于尚未建立自动功能测试框架（正在开发中），我们需要手动进行此测试。

未解决的问题

此 BP 与 Auth 密切相关，因为镜像列表请求发生在客户的上下文中。由于 Auth 目前仍然是一个不断变化的目标，因此 OpenStack API 与 Auth 系统之间的交互是一个问号。

BoF 议程和讨论

镜像列表将如何与 OpenStack API auth 机制交互。

有多少潜在的 OpenStack 部署者想要了解实例的镜像？（例如，Rackspace 是唯一的吗？还是每个人都想要这个？）

---