Glance 中支持特性

https://blueprints.launchpad.net/nova/+spec/glance-image-traits

此蓝图建议扩展计算实例的精细调度，以使用 Glance 镜像元数据提供的特性，以及风味提供的特性[1]。

问题描述

当前，调度器仅在

  1. 管理员创建具有所需特性的风味时

  2. 用户从列表中选择具有所需特性的正确风味时

云管理员可能希望将一些定性属性直接放在工作负载镜像上，以控制这些工作负载将在哪里被调度。然后，这些属性可以作为调度器的提示，以便它可以选择能够支持这些工作负载的正确计算主机集，而无需预先创建风味，也无需用户选择正确的风味。

镜像上的属性可用于指定主机上所需的特性，类似于风味上的特性。例如，对特定 CPU 指令集、NIC 功能或是否为受信任主机等的支持。

用例

作为云管理员，我希望能够进一步控制某些工作负载可以在哪里启动和运行。

例如，如果工作负载实例将应用加密算法或处理隐私数据，则实例可能需要在主机上具有特定的功能/特性。

管理员可以将这些功能需求作为所需的特性添加到 Glance 镜像中。这将允许 Nova 调度器自动选择仅具有这些特性的主机。

对于管理用户

  • 允许管理员指定镜像所需的特性集。

提议的变更

当前，风味中指定的特性信息作为启动请求的一部分被收集。此信息提供给 Placement API，Placement API 使用它来过滤掉未与这些特性关联的资源提供者。

我们建议允许在镜像元数据中指定特性，使其成为启动请求工作流程的一部分。启动请求将组合风味和镜像元数据提供的特性信息，形成两者的并集。此并集将传递给 Placement API 以生成分配候选者。

Glance 镜像已经允许用户指定额外的属性作为键值对。我们将重用 Nova 用于在 Nova 风味元数据项中编码特性信息相同的机制。

我们建议添加 trait: 作为前缀，以便我们可以重用风味 extra_specs 中指定的特性的相同命名空间。

Glance 镜像的附加属性中的特性语法如下所示

trait:HW_CPU_X86_AVX2=required
trait:CUSTOM_TRUSTED_HOST=required

目前，唯一有效的值是 required。作为此更改的一部分，对镜像附加属性中指定的特性的验证不在范围内。

由于尝试在镜像和风味之间协调 精细请求组 的难度，仅支持（未编号的）trait 组。该组中的特性将与风味中未编号请求组的特性合并。

基于 ironic driver traits spec 实现，我们需要以类似于将 extra_specs 特性发送到 ironic 的方式将镜像特性发送到 ironic。

处理重建

在用新镜像重建（主机和风味保持不变）的情况下，我们需要确保镜像特性（如果已更新）被考虑在内。理想情况下，调度器将从 placement 请求新的候选者，并确保当前主机位于该列表中，但这在计算资源接近饱和时存在问题，因为当前主机将被排除在外。这在 issue rebuild should not check with placement 中有描述。

为了解决上述问题，conductor 可以在重建请求上执行 pre-flight 检查，以确保镜像特性仍然可以在该实例的当前分配中容纳。

Conductor 可以使用 GET /allocations/{instance_uuid} 请求当前实例的分配，并从分配中收集所有资源提供者及其相应的特性。然后，它可以检查是否缺少任何请求的镜像特性。如果有任何缺失的特性，我们可以拒绝重建。

备选方案

继续使用启动请求中风味提供的特性作为当前模型。

这意味着云管理员需要创建具有工作负载镜像所需的特性的特定风味，并且最终用户需要选择具有配置的特性的风味。

另一个需要考虑的方面是，由于风味描述了请求的定量和定性方面，如果给定混合的工作负载，风味的數量需要大幅增加。

在典型的 Openstack 安装中，如果需要为每个风味添加一个特性，我们将最终得到 14 个风味。如果需要添加特性组合以及定量方面，这个数字会迅速增长。

另一种潜在的替代方案是将特性直接作为实例启动请求的一部分提供。但这与最终用户忘记选择正确的特性存在相同的问题。

使用基于镜像的特性，管理员只需在镜像上设置特性一次，该方法可以避免用户在启动期间出错。

另一种替代方案是使用 AggregateImagePropertiesIsolation 过滤器来过滤特定主机聚合内的选定主机。主机聚合元数据不像特性那样标准化，还需要预先创建具有重复标准特性的主机聚合，这并不理想。

处理重建

参见 rebuild should not check with placement

方案 1

如果镜像的所需特性已从原始镜像更改，我们可以在 API 层使用明确的错误消息拒绝重建请求。这是一种更简单的方法，但存在缺点。

在用户尝试进行有效重建的情况下，由于旧镜像特性 != 新镜像特性，请求将被拒绝。这似乎给用户和管理员带来了不必要的痛苦。

方案 2

调度器可以使用现有的 GET /resource_providers/{UUID}/traits API 请求当前主机的特性，并尝试将返回的当前主机特性与镜像中指定的特性进行匹配。

如果特性不匹配，将在运行过滤器之前引发 NoValidHost 异常。如果特性匹配，则请求将继续处理，就像当前一样（通过各种过滤器等）。

潜在的问题是，镜像上的特性可能附加到计算节点下的嵌套资源提供者。例如，如果实例正在运行具有两个 SRIOV nic 的主机。一个是普通的 SRIOV nic，另一个具有某种卸载功能。

所以，原始请求是

resources=SRIOV_VF:1

实例从普通的 SRIOV nic 获取 VF。

但是使用新的镜像，新的请求是

resources=SRIOV_VF:1
traits=HW_NIC_OFFLOAD_XX

为了处理嵌套资源提供者并收集它们的特性，我们可能需要对树中的每个资源提供者执行多次 GET /resource_providers/{UUID}/traits。

理想情况下，此请求应该失败，因为我们无法确保从另一个 SRIOV PF 分配 VF。

此替代方案也可以在重建时在 ImagePropertiesFilter 中实现。但这并不理想，因为其他过滤器都不会在过滤过程中进行任何 API 调用。

其他替代方案

邮件列表中讨论了其他一些替代方案 [2]。

数据模型影响

更新 ImageMetaProps 类以返回键值对形式的特性

REST API 影响

无。

安全影响

无。

通知影响

无。

其他最终用户影响

无。

性能影响

无。

其他部署者影响

无。

开发人员影响

无。

升级影响

无。

实现

负责人

主要负责人

Arvind Nadendla <arvind.nadendla@intel.com>

其他贡献者

Mohammed Karimullah <karimullah.mohammed@intel.com>

工作项

  • 更新 ImageMetaProps 类以返回特性

  • 更新 Nova 调度器以从 ImageMeta 中提取属性，并将其传递给 Placement API

  • 更新 Nova Conductor，以便在重建期间验证镜像特性是否与实例的现有分配匹配

  • 需要更新 ironic virt 驱动程序，以根据 ironic driver traits spec 将镜像中的特性推送到节点

依赖项

无。

测试

将添加用于构建请求的单元测试和功能测试。

文档影响

参考资料

历史

修订版

发布名称

描述

Rocky

引入