提供商配置文件¶

https://blueprints.launchpad.net/nova/+spec/provider-config-file

这是一个使用标准 YAML 文件格式配置资源提供商库存和特性的提案。

注意

这项工作源自 Jay 的 Rocky provider-config-file 提案和 Konstantinos 的 device-placement-model 规范（该规范源自 Eric 的 device-passthrough 规范），但在几个实质性方面有所不同。

注意

这项工作受到 Nova 支持非原生计算资源的需求的影响，这些资源由资源管理守护进程进行更细粒度的控制。PTG 讨论记录可在资源管理守护进程_PTG 摘要中找到

注意

我们目前将提供商配置 YAML 的所有权和使用限制在 Nova 范围内，如文件格式所述。

注意

目前，提供商配置仅接受放置覆盖，以创建和管理不由 Nova virt 驱动程序原生管理的资源的库存和特性。

注意

本规范旨在定义 a) 当前活动用例的文件格式，以及 b) Nova 对这些文件的使用。后续功能可以定义框架被其他消费者使用或为了满足特定用例而增强的语义。

问题描述¶

为了便于 Nova 内部代理（例如 virt 驱动程序和 PCI 直通子系统）在放置 API 中正确管理资源提供商信息，我们需要一种表达资源提供商信息各种覆盖的方式。虽然我们可以继续使用许多现有和新的配置选项来表达这些信息，但拥有标准化的、版本化的提供商描述文件格式可以让我们将提供商信息的管理与管理这些资源提供商的服务或守护程序的配置分离。

用例¶

请注意，此处定义的文件格式/模式旨在适应以下用例。文件格式/模式当前解决了需要更改 Nova 中 virt 驱动程序使用的资源提供商信息的一些用例，但它应该允许选项进行扩展，以便 Nova 或其他服务在问题陈述中描述的将来使用。

库存定制¶

操作员希望描述新平台功能的库存

这些功能可能是实验性的，或者尚未完全被 Nova 支持。期望 Nova 可以管理这些库存，并帮助调度请求支持新平台功能的工作负载到其容量。例如，报告 CUSTOM_LLC（最后一级缓存）库存。

本规范定义的文件必须允许其作者

明确地标识提供商。
创建和管理 Nova virt 驱动程序未原生管理的资源类别的库存（CUSTOM_LLC、CUSTOM_MEMORY_BANDWIDTH 等）

特性定制¶

操作员希望将新的自定义特性与提供商关联。

这些功能可能是实验性的，或者尚未完全被 Nova 支持。期望 Nova 可以管理这些特性，并帮助调度支持新平台功能的工作负载到其特性。

本规范定义的文件必须允许其作者

明确地标识提供商。
指定要与提供商关联的任意自定义特性。

提议的变更¶

提供商配置文件模式¶

提出了一种带有正式模式的版本化 YAML 文件格式。本规范的范围是模式、将文件解析为 Python 字典的代码、将字典与模式进行验证的代码以及将结果字典与资源跟踪器处理的提供商树合并的代码。

该代码最初将引入到 openstack/nova 项目中，并由资源跟踪器使用。如果它可以为 Nova 之外的消费标准化，则其中一些部分（例如模式定义、文件加载和验证）可以在将来移动到单独的 oslo-ish 库中。

以下是文件格式的简化伪模式。

meta:
  # Version ($Major, $minor) of the schema must successfully parse documents
  # conforming to ($Major, *). I.e. additionalProperties must be allowed at
  # all levels; but code at a lower $minor will ignore fields it does not
  # recognize. Schema changes representing optional additions should bump
  # $minor. Any breaking schema change (e.g. removing fields, adding new
  # required fields, imposing a stricter pattern on a value, etc.) must bump
  # $Major. The question of whether/how old versions will be deprecated or
  # become unsupported is left for future consideration.
  schema_version: $Major.$minor

providers:
  # List of dicts
    # Identify a single provider to configure.
    # Exactly one of uuid or name is mandatory. Specifying both is an error.
    # The consuming nova-compute service must fail if the same provider is
    # specified more than once across all provider configs.
    # NOTE: Caution should be exercised when identifying ironic nodes,
    # especially via the `$COMPUTE_NODE` special value. If an ironic node
    # moves to a different compute host with a different provider config, its
    # attributes will change accordingly.
  - identification:
        # UUID of the provider.
        # The uuid can be set to the specialized string `$COMPUTE_NODE` which
        # will cause the consuming compute service to apply the configuration
        # in this section to all nodes it manages.
        uuid: ($uuid_pattern|"$COMPUTE_NODE")
        # Name of the provider.
        name: $string
    # Customize provider inventories
    inventories:
        # This section allows the admin to specify various adjectives to
        # create and manage providers' inventories.  This list of adjectives
        # can be extended in the future as the schema evolves to meet new
        # use cases. For now, only one adjective, `additional`, is supported.
        additional:
            # The following inventories should be created on the identified
            # provider. Only CUSTOM_* resource classes are permitted.
            # Specifying inventory of a resource class natively managed by
            # nova-compute will cause the compute service to fail.
            $resource_class:
                # `total` is required. Other optional fields not specified
                # get defaults from the Placement service.
                total: $int
                reserved: $int
                min_unit: $int
                max_unit: $int
                step_size: $int
                allocation_ratio: $float
            # Next inventory dict, keyed by resource class...
            ...
    # Customize provider traits.
    traits:
        # This section allows the admin to specify various adjectives to
        # create and manage providers' traits.  This list of adjectives
        # can be extended in the future as the schema evolves to meet new
        # use cases. For now, only one adjective, `additional`, is supported.
        additional:
            # The following traits are added on the identified provider. Only
            # CUSTOM_* traits are permitted. The consuming code is
            # responsible for ensuring the existence of these traits in
            # Placement.
            - $trait_pattern
            - ...
  # Next provider...
  - identification:
    ...

示例¶

注意

本节旨在从高级别描述如何使用此文件格式来提供 CUSTOM_LLC 库存信息。

注意

本节旨在从高级别描述如何使用此文件格式来提供 P 状态计算特性信息。

meta:
  schema_version: 1.0

providers:
  # List of dicts
  - identification:
        uuid: $COMPUTE_NODE
    inventories:
        additional:
            CUSTOM_LLC:
                # Describing LLC on this compute node
                # max_unit indicates maximum size of single LLC
                # total indicates sum of sizes of all LLC
                total: 22
                reserved: 2
                min_unit: 1
                max_unit: 11
                step_size: 1
                allocation_ratio: 1
    traits:
        additional:
            # Describing that this compute node enables support for
            # P-state control
            - CUSTOM_P_STATE_ENABLED

Nova 中提供商配置的消费¶

提供商配置处理将由 nova-compute 进程执行，如下所述。virt 驱动程序没有更改。特别是，virt 驱动程序无法控制提供商配置的加载、解析、验证或集成。如果证明有必要，可以在将来添加这种控制。

配置

引入了一个新的配置选项

[compute]
# Directory of yaml files containing resource provider configuration.
# Default: /etc/nova/provider_config/
# Files in this directory will be processed in lexicographic order.
provider_config = $directory

加载、解析、验证

在 nova-compute 启动时，CONF.compute.provider_config 中的文件会被标准库（例如 yaml）加载和解析，并进行模式验证（例如通过 jsonschema）。模式验证失败会导致 nova-compute 启动失败。在成功加载和验证后，生成的数据结构将存储在 ResourceTracker 的实例属性中。

提供商树合并

将编写一个通用（非特定于 hypervisor/virt）的方法，将 provider config 数据合并到现有的 ProviderTree 数据结构中。该方法必须检测冲突，即 provider config 数据引用由 virt 驱动程序管理的资源类的库存。冲突应记录警告，并导致冲突的配置库存被忽略。此方法的具体位置和签名，以及它如何检测冲突，由实现决定。

_update_to_placement

在 ResourceTracker 的 _update_to_placement 流程中，在 update_provider_tree 和自动特性处理之后调用合并方法，仅在 update_provider_tree 流程中（不在遗留的 get_inventory 或 compute_node_to_inventory_dict 流程中）。在启动时（startup == True），如果合并检测到冲突，nova-compute 服务将失败。

备选方案¶

目前，通过 oslo.config 选项进行临时提供商配置，并且更多选项正在被提出或考虑以处理 VGPU、NUMA、带宽资源等。表达分层数据结构的笨拙导致了诸如 [pci]passthrough_whitelist 和动态配置机制之类的错误，其中配置组及其选项是动态创建的。YAML 本身非常适合此目的，因为它旨在清晰地表达任意嵌套的数据结构，而无需使用嘈杂的标点符号。此外，模式是自文档化的。

数据模型影响¶

无

REST API 影响¶

无

安全影响¶

管理员应确保提供商配置文件具有适当的权限和所有权。消费服务可能希望检查这一点，并在文件由流程所有者以外的任何人可写时生成错误。

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

无

其他部署者影响¶

只有当操作员希望进行 provider 自定义时，才需要理解此文件及其含义。

开发人员影响¶

需要后续规范来服务于此文件格式。

升级影响¶

无。（此文件格式的消费者需要解决此问题 - 例如，决定如何弃用正在被替换的现有配置选项）。

实现¶

负责人¶

主要负责人: dustinc
其他贡献者: efried dakshinai

工作项¶

构建正式模式
实现解析和模式验证
实现将配置合并到提供商树
将上述内容合并到 ResourceTracker 中
编写自文档化示例文件

依赖项¶

无

测试¶

将对模式验证进行单元测试。
功能和集成测试，以将来自提供商配置文件的新增内容通过 Nova virt 驱动程序移动到 Placement。

文档影响¶

正式模式文件和提供商配置文件的自文档化示例文件。
管理员面向的文档，介绍如何更新文件以及 Nova 如何处理更新。
用户面向的文档（包括发行说明）。

参考资料¶

历史¶

修订版¶
发布名称	描述
Stein	引入
Train	重新引入，简化

提供者配置文件

提供商配置文件¶

问题描述¶

用例¶

库存定制¶

特性定制¶

提议的变更¶

提供商配置文件模式¶

示例¶

Nova 中提供商配置的消费¶

备选方案¶

数据模型影响¶

REST API 影响¶

安全影响¶

通知影响¶

其他最终用户影响¶

性能影响¶

其他部署者影响¶

开发人员影响¶

升级影响¶

实现¶

负责人¶

工作项¶

依赖项¶

测试¶

文档影响¶

参考资料¶

历史¶

Nova Specs

页面内容