添加节点 resource_class 字段

https://bugs.launchpad.net/ironic/+bug/1604916

Nova 计划以与其他 nova 资源相同的方式调度 ironic 资源,这涉及到将每个 ironic 节点变成一个“资源提供者”,它具有一个“资源类别”。该资源类别由 nova flavor 引用,简而言之,flavor 需要来自该资源类别恰好一个东西。在运行资源跟踪器时,nova 必须能够将每个 ironic 节点与一个资源类别关联起来,运营商必须能够指定它(因为运营商是创建 flavor 的人,并且需要知道如何将 flavor 与之关联)。为了允许这样做,我们在 ironic 的节点对象中添加了一个新的“resource_class”字段。

问题描述

目前,nova 使用 (host, node) 元组来跟踪 ironic 资源。这在 nova 内部引起了许多问题,nova 团队正在努力摆脱这种方式。与此同时,nova 希望以与其他实例相同的方式调度 ironic 实例。这允许 ironic 沿着正在进行的调度器更改一起发展,这将有助于减少(或最终消除)调度竞争,并受益于即将到来的其他调度器优化(例如使定性决策更有效)。

提议的变更

nova 当前的提议是使每个 ironic 节点成为一个“资源提供者”,它与一个“资源类别”相关联。[0] 一个 nova flavor 可以声明它需要给定资源类别的一些数量;在 ironic 的情况下,它需要一个且仅需要一个。 ironic 节点的资源提供者记录将声明它提供恰好 1 个(或 0 个,如果它处于维护或类似状态)的资源类别,用于该提供者记录。

该提议仍然允许根据定性属性(例如功能或亲和性规则)来调度节点。资源类别在这种情况下只是第一个“过滤器”(尽管它不是传统的调度器过滤器)。

为此,nova 需要知道资源提供者记录需要与哪个资源类别关联。由于运营商管理将与这些类别链接的 flavor,我们需要一种方法让运营商指定每个节点所属的类别,以便正确链接 flavor。因此,我们在 ironic 的节点记录中添加了一个“resource_class”字段,nova 将在创建资源提供者记录时使用它。

例如,假设一个 ironic 部署具有以下节点

- node-1:
  resource_class: ironic-gold
  properties:
    cpus: 4
    memory_mb: 16384
    capabilities:
      boot_mode: uefi,bios
- node-2:
  resource_class: ironic-silver
  properties:
    cpus: 2
    memory_mb: 8192

运营商可能会这样定义 flavor

- baremetal-gold
  resources:
    ironic-gold: 1
  extra_specs:
    capabilities: boot_mode:bios
- baremetal-gold-uefi
  resources:
    ironic-gold: 1
  extra_specs:
    capabilities: boot_mode:uefi
- baremetal-silver
  resources:
    ironic-silver: 1

请注意,flavor 定义是一个草案,可能不是实现时实际使用的键。

使用 baremetal-gold 或 baremetal-gold-uefi flavor 启动实例的 nova 用户将降落在 node-1 上,因为功能仍然可以传递到 ironic,并且节点上的 resource_class 与 flavor 所需的匹配。baremetal-silver flavor 将匹配 node-2。

备选方案

如果一直这样做 (host, node),最终 nova 团队可能会决定从 nova 中删除我们的驱动程序,并随后删除 (host, node) 元组并严重破坏我们的驱动程序。

数据模型影响

在节点表中添加一个“resource_class”字段。这将是一个 VARCHAR(80),因为它与 nova 的表结构匹配。此更改将提供数据迁移。对象 API 也会采用此更改,并进行相应的版本更新。这将默认为 NULL。

状态机影响

无。

REST API 影响

新的“resource_class”字段将像任何其他字符串字段一样暴露在 API 中,具有相同的语义。

此字段的默认策略应与驱动程序、网络接口等相同。

将添加对此字段的过滤和排序。

将进行微版本更新,如往常一样。

客户端 (CLI) 影响

客户端将被更新以添加该字段。

“ironic” CLI

CLI 将被更新以添加该字段。

“openstack baremetal” CLI

CLI 将被更新以添加该字段。

RPC API 影响

仅上述对象更改。

驱动程序 API 影响

无。

Nova 驱动程序影响

立即,我们将 resource_class 字段传回资源跟踪器,以便 nova 可以在 Newton 中将这些资源放入 placement 数据库。这将需要一个小的补丁来更新我们使用的 API 版本并将该字段传回 resource_dict。这需要一个发布说明,说明 ironicclient 版本和运行此代码所需的可用 API 版本。

在 Ocata 期间,将对调度器进行工作以将其用于调度,但是这超出了 ironic 驱动程序的范围。

Ramdisk 影响

无。

安全影响

无。

其他最终用户影响

无。

可扩展性影响

无。

性能影响

无。

其他部署者影响

部署了 Newton 版本的 nova 后,部署者需要在 ironic 中填充 resource_class 字段,并在部署 Ocata 版本的 nova 之前关联 flavor。

开发人员影响

无。

实现

负责人

jroll

工作项

  • 将字段添加到 DB。

  • 将字段添加到对象模型。

  • 将字段添加到 API,并进行过滤和排序。

  • 更新安装指南等文档。

依赖项

无。

测试

此处应足以进行单元测试。

升级和向后兼容性

没有直接影响,但重要的是要注意,在 Ocata 版本的 nova 中调度仍然会回退到旧方法,如果任何节点的 resource_class 设置为 NULL。运营商应该在 nova 的 P 版本之前填充此数据。

文档影响

将新字段添加到 API 参考。

我们还需要更新安装指南和任何其他讨论使用 ironic 设置 nova 的文档,以确保部署者在添加节点时设置此字段。这还需要通过发布说明(可能还有 ops 列表电子邮件)进行极其明确的沟通。

参考资料

[0] https://review.opendev.org/#/c/312696