Flavor Extra Spec 验证规范 (扩展)¶

https://blueprints.launchpad.net/nova/+spec/flavor-extra-spec-image-property-validation-extended

引入一个基于 YAML 的模式，用于描述 flavor extra specs、镜像元数据属性以及它们之间的关系。

问题描述¶

Flavor extra specs 是 nova 中一个比较混乱的部分。我们希望解决以下几个问题

许多 flavor extra specs 和镜像元数据属性缺乏文档说明 [1]。是的，我们有 Glance 镜像元数据定义，但它们通常比较过时，nova 无法/不能使用它们，而且它们并非面向用户文档。
过时、不完整或不正确的 Glance 元数据定义。
如果在 extra spec 中输入错误，导致行为与预期不符，则不会发出警告。
没有定义的方法来弃用 flavor extra spec，导致重复造轮子。

用例¶

作为部署者，我希望知道有哪些可用的 flavor extra specs 和镜像元数据属性，以及为什么我想使用它们。
作为部署者，我希望 nova 在我使用了不存在或拼写错误的 flavor extra spec 时告诉我。
作为开发者，我希望有一个简单的方法来弃用 flavor extra specs，随着我们将专用 CPU 的跟踪迁移到 placement，这种情况只会变得越来越普遍。
作为文档编写者，我希望能够交叉引用各种可用的 flavor extra specs 和镜像元数据属性。

提议的变更¶

Flavor extra spec 是一对键值对。例如

hw:cpu_policy=dedicated

验证 extra spec 的 *值* 部分与 *键* 部分需要不同的解决方案。此规范旨在解决 *键* 和 *值* 的验证问题，首先从后者开始，然后转向前者。

以下内容不在此次变更范围内

强制执行 extra spec 依赖关系。例如，如果 extra spec A 要求先配置 extra spec B。我们将记录依赖关系，但不会强制执行。
强制执行 virt 驱动程序依赖关系。不幸的是，虽然 flavor extra specs 应该是通用的，但并非总是如此。如上所述，我们将记录此依赖关系，但不会强制执行。
严格强制执行键验证。最终，我们希望跟踪所有可能的 extra spec 名称，并对错误的键值发出警告或错误，但这可能需要一些时间才能完善。在此期间，我们将仅仅记录这些潜在的错误值。

此变更建立在 Flavor extra spec image metadata validation <https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/flavor-extra-spec-image-property-validation.html> 的基础上，它为我们解决了其中一些问题。

值验证¶

值验证是这两个问题中更容易解决的一个。它将以通用方式解决以下问题

hw:cpu_policy=deddddicated

对于通用的 extra spec，验证器的定义需要包含以下内容

extra spec 的名称或 *键*，例如，上述示例中的 cpu_policy
extra spec 的命名空间，例如，上述示例中的 hw
extra spec 的描述
extra spec 的支持状态
有效值；它是一个整数、一个自由格式字符串、一个匹配给定正则表达式的字符串、一个枚举，或者其他任何东西
virt 驱动程序依赖关系；这仅用于文档说明，不会强制执行
extra spec 依赖关系；这仅用于文档说明，不会强制执行

对于许多 extra spec 命名空间，我们建议在树中维护定义。为此，我们建议添加一个新的模块，nova.api.validation.extra_specs，它将包含 *flavor validators* 的定义。这些将使用两个新的基类定义，BaseValidator 和 BaseExtraSpec。BaseValidator 将被子类化以表示命名空间，而 BaseExtraSpec 将被子类化以表示单个 extra spec。BaseExtraSpec 子类将再次注册到命名空间。

例如

class HWValidator(BaseValidator):
    """A validator for the ``hw`` namespace."""
    name = 'hw'
    description = (
        'Extra specs that modify behavior of the virtual hardware '
        'associated with instances.'
    )

class CPUPolicy(BaseExtraSpec):
    """A validator for the ``hw:cpu_policy`` extra spec."""
    name = 'cpu_policy'
    description = (
        'The policy to apply when determining what host CPUs the guest '
        'CPUs can run on. If ``shared`` (default), guest CPUs can be '
        'overallocated but cannot float across host cores. If '
        '``dedicated``, guest CPUs cannot be overallocated but are '
        'individually pinned to their own host core.'
    )
    deprecated = True
    value = {
        'type': str,
        'description': 'The CPU policy.',
        'enum': [
            'dedicated',
            'shared'
        ],
    }

class NUMACPUs(BaseExtraSpec):
    """A validator for the ``hw:numa_cpu.{id}`` extra spec."""
    name = 'numa_cpu.{id}'
    description = (
        'A mapping of **guest** CPUs to the **guest** NUMA node '
        'identified by ``{id}``. This can be used to provide asymmetric '
        'CPU-NUMA allocation and is necessary where the number of guest '
        'NUMA nodes is is not a factor of the number of guest CPUs.'
    )
    params = [
        {
            'name': 'id',
            'type': int,
            'description': 'The ID of the **guest** NUMA node.',
        },
    ]
    value = {
        'type': str,
        'description': (
            'The guest CPUs, in the form of a CPU map, to allocate to the '
            'guest NUMA node identified by ``{id}``.'
        ),
        'pattern': r'\d+((-\d+)?(,\^?\d+(-\d+)?)?)*',
    }

register(HWValidator, CPUPolicy)
register(HWValdiator, NUMACPUs)

虽然许多定义将在树中维护，但某些命名空间需要特殊处理，因为它们由外部服务拥有，例如 traits 命名空间（由 os-traits 拥有）或 accel 命名空间（拟用于 cyborg）。对于这些，我们建议使用 stevedore 允许外部项目注册自定义验证器。例如，nova 将提供以下内容

nova.extra_spec_validators =
    hw = nova.api.validation.extra_specs:HWValidator
    os = nova.api.validation.extra_specs:OSValidator
    traits = nova.api.validation.extra_specs:TraitsValidator
    resources = nova.api.validation.extra_specs:ResourcesValidator
    custom = nova.validators.extra_specs:NoopValidator
    * = nova.validators.extra_specs:YAMLValidator

Cyborg 可以通过提供如下内容来扩展它

nova.extra_spec_validators =
    accel = cyborg.extra_specs_validator:AccelValidator

最后，有一些 extra specs 是由操作员定义的，因此服务不会知道它们。对于这些，我们建议引入一个模式定义文件。这是一个 YAML 格式的文件，用于描述可用的 flavor extra specs。选择 YAML 格式是因为它允许我们以声明方式定义规范，而无需编写 Python 代码。此文件的格式仍然会镜像 Python 对象的格式。例如

---
version: 1.0
metadata:
- name: numa_nodes
  namspace: hw
  description: >
    The number of NUMA nodes the instance should have.
  value:
    type: integer
    description: >
      The number of NUMA nodes the instance should have.

- name: numa_cpus.{id}
  namspace: hw
  description: >
    A mapping of **guest** CPUs to the **guest** NUMA node identified by
    ``{id}``. This can be used to provide asymmetric CPU-NUMA allocation
    and is necessary where the number of guest NUMA nodes is is not a
    factor of the number of guest CPUs.
  parameters:
  - name: id
    type: integer
    description: >
      The ID of the **guest** NUMA node.
  value:
    type: string
    format: '\d+((-\d+)?(,\^?\d+(-\d+)?)?)*'
    description: >
      The guest CPUs, in the form of a CPU map, to allocate to the guest
      NUMA node identified by ``{id}``.

无论 extra spec 验证器的来源如何，它们都将由 openstack flavor set 命令背后的 API 使用。将引入一个微版本用于此命令，以避免破坏意外设置错误值的现有工具。

键验证¶

我们还希望能够捕获无效的 extra specs 本身。它将以通用方式解决以下问题

hw:cpu_pollllicy=dedicated

这涉及维护一个有效的 extra spec 注册表。并非所有 extra spec 都可以提前知道，对于动态 extra spec，例如在 Support filtering by forbidden aggregate membership <https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/negative-aggregate-membership.html> 中提出的那些，我们可以依赖于操作员提供的自定义命名空间验证器或 YAML 规范。但是，完成此注册表（在树中和树外）预计将是一项复杂的努力，因此，在此规范中，我们不会强制执行键的验证。

其他变更¶

我们还建议添加工具来 (a) 从定义渲染 reStructuredText 文档，以及 (b) 将定义转换为 Glance 元数据定义文件。这两个工具都将位于 nova 树中，允许我们成为这些内容的唯一事实来源。

备选方案¶

我们可以忽略上述一些问题，并尝试以分阶段的方式解决其他问题。这可能更加繁琐且耗时，因为需要在更多地方进行修改。

数据模型影响¶

无。

REST API 影响¶

我们将向 POST flavors/{flavor_d}/os-extra_specs API 添加一个 REST API 微版本，以捕获无效的 flavor extra specs。

安全影响¶

无。

通知影响¶

无。

其他最终用户影响¶

最终用户将获得有关可用 flavor extra specs 和镜像元数据属性的更好的文档。

性能影响¶

无。

其他部署者影响¶

操作员现在需要将新的 flavor extra specs 添加到 YAML 模式文件中，否则在使用新的 API 微版本时会看到错误。

开发人员影响¶

开发者现在应该将新的 flavor extra specs 添加到 nova.compute.extra_specs 模块，以利用可用的验证功能。

升级影响¶

无。

实现¶

负责人¶

主要负责人: stephenfinucane
其他贡献者: 无

工作项¶

为所有树内 flavor extra specs 生成 extra spec 定义。
添加代码以在实例创建、调整大小和重建操作期间，将此与镜像元数据属性和 flavor extra specs 进行验证。
添加一个 Sphinx 扩展，以将此规范渲染为文档，并添加另一个工具将规范转换为 Glance 元数据定义。
添加 YAML 格式定义解析器，并记录操作员如何使用它。

依赖项¶

无。

测试¶

单元测试。

文档影响¶

通过 Sphinx 的力量，将会有更好的文档。

参考资料¶

历史¶

修订¶
发布名称	描述
Train	引入

Flavor Extra Spec 验证（扩展）

Flavor Extra Spec 验证规范 (扩展)¶

问题描述¶

用例¶

提议的变更¶

值验证¶

键验证¶

其他变更¶

备选方案¶

数据模型影响¶

REST API 影响¶

安全影响¶

通知影响¶

其他最终用户影响¶

性能影响¶

其他部署者影响¶

开发人员影响¶

升级影响¶

实现¶

负责人¶

工作项¶

依赖项¶

测试¶

文档影响¶

参考资料¶

历史¶

Nova Specs

页面内容