添加节点 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 定义只是一个草案，在实现时可能不是实际使用的键。
nova 用户使用 baremetal-gold 或 baremetal-gold-uefi flavor 启动实例时，将降落在 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 中，具有相同的语义。
此字段的默认策略应与 driver、network_interface 等相同。
将添加对此字段的过滤和排序。
将进行微版本更新，如往常一样。
客户端 (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 字段，并关联 flavor，然后才能部署 Ocata 版本的 nova。
开发人员影响¶
无。
实现¶
负责人¶
jroll
工作项¶
将字段添加到 DB。
将字段添加到对象模型。
将字段添加到 API，并进行过滤和排序。
更新安装指南等文档。
依赖项¶
无。
测试¶
此处应足以进行单元测试。
升级和向后兼容性¶
没有直接影响，但重要的是要注意，在 Ocata 版本的 nova 中调度仍然会回退到旧方法，如果任何节点的 resource_class 设置为 NULL。运营商应该在 nova 的 P 版本之前填充此数据。
文档影响¶
将新字段添加到 API 参考。
我们还需要更新安装指南和任何其他讨论使用 ironic 设置 nova 的文档，以确保部署者在添加节点时设置此字段。这还需要通过发布说明（可能还有 ops 列表电子邮件）进行极其明确的沟通。
