资源提供者 - 介绍资源类

https://blueprints.launchpad.net/nova/+spec/resource-classes

此蓝图引入了一种机制，用于表示系统可能提供的定量资源类型。

问题描述

目前，Nova 中暴露的定量资源类型被硬编码在代码库的各个地方。例如，在 Instance 对象上，我们存储请求的 vCPU 数量在 vcpus 字段中，RAM 数量在 memory_mb 字段中。我们有一个单独的 instance_pci_devices 表在数据库中用于 PCI 资源类型。我们将与 NUMA 相关的资源信息存储在不同表中的一个字段中，等等。

每当我们想提供一类新的资源时，最终都会创建一个新的表字段或整个新的数据库表来处理这种新的资源类型。每次我们更改数据库模式时，都会给系统带来一定程度的停机时间。然而，这些更改是不必要的。我们应该能够添加新的资源类到系统中，而无需更改数据库模式，并且这一系列蓝图为实现这一目标奠定了基础。

这项工作还将使我们能够拥有一个通用的资源池系统，该系统不会将资源类硬编码到数据库字段名称中。与其拥有一个仅跟踪共享磁盘存储的表，我们可以拥有一个可用于跟踪许多不同类型资源的数据库表，并且当添加对更多类型共享资源的支持时，此表的模式无需更改。

用例

作为云部署者，我希望减少因数据库模式更改而导致的停机时间，尤其是在向系统中添加新的资源类型（或以新的方式处理现有类型的资源）时。

提议的变更

我们建议添加一种新的 Nova 对象字段类型，称为 ResourceClassField，它源自 nova.objects.fields.EnumType 对象。ALLOWED 字段的值将是一组商定的常量。我们不建议添加操作员对该常量列表的可扩展性，因为我们不想鼓励两个 OpenStack 云对同名的资源类有不同的定义的情况。

备选方案

我们可以继续像以前一样做事，每次添加系统提供的新的资源类时，添加新的模式字段或新的模式表。

数据模型影响

将引入一种新的 nova 对象字段类型，用于资源类。

最初，我们可以将枚举填充为系统中已知的资源类

  • VCPU

  • MEMORY_MB

  • DISK_GB

  • PCI_DEVICE

  • SRIOV_NET_VF

  • NUMA_SOCKET

  • NUMA_CORE

  • NUMA_THREAD

  • NUMA_MEMORY_MB

  • IPV4_ADDRESS

REST API 影响

目前没有。将来，我们可能希望允许云用户通过 HTTP 查询资源类，但最初我认为这没有必要。

安全影响

无。

通知影响

无。

其他最终用户影响

未来的工作可以引入一个 nova resource-class-list 命令，但是这对于此蓝图规范来说并不重要。

性能影响

此蓝图没有引入任何内容，因为我们只是在 Enum 类型的字段中添加一组常量。

其他部署者影响

无。

开发人员影响

无。

实现

负责人

主要负责人

cdent

其他贡献者

jaypipes

工作项

  • 创建新的 nova.objects.fields.ResourceClassField nova 字段

依赖项

无。

测试

对于这个小蓝图规范，单元测试就足够了。功能和集成测试更适合于构建在此工作之上的规范，例如 generic-resource-pools。

文档影响

无。

参考资料

历史

修订版

发布名称

描述

Mitaka

引入