检索支持的卷类型附加规格

https://blueprints.launchpad.net/cinder/+spec/get-volume-type-extra-specs

提供一个接口来获取卷驱动程序的能力

问题描述

定义

  • 卷类型: 一组卷策略。

  • 附加规格: 卷类型的定义。这是一组将在创建卷时使用的策略,例如配置类型、QoS。

  • 能力: Cinder 中当前部署的后端能够执行的操作。这些对应于附加规格。

目前 Horizon 和 cinder 客户端中的卷类型附加规格管理流程容易出错。操作员管理附加规格,但缺乏关于后端可能实现哪些能力的指导。在不知道能力的情况下,操作员不知道可能的附加规格键/值是什么。

目前操作员必须确保他们阅读的是与存储后端版本相对应的正确文档。文档可能会过时,与他们的卷驱动程序不一致。

如果操作员能够向 Cinder 询问当前部署的存储后端的capabilities,而不是猜测,那将会更方便,用户体验也会更好。

用例

作为操作员,我希望获取 Cinder 中已部署存储后端的能力列表。

有了这些能力,我就有了可以在卷类型的附加规格中使用的键和可能的值。

潜在地,API 端点可以用于改进 Horizon 中管理附加规格的 GUI。

提议的变更

Cinder 卷驱动程序将实现一个新的方法 get_capabilities,它将返回存储后端支持的capabilities的字典。

字典将包含一些关于后端的简要信息,以及对应于附加规格键和值的capabilities。

诸如创建卷、创建快照等功能被认为是最低功能 [1]。与 明确定义 的键 [2] 不同,最低功能是必需实现的。对于 明确定义 的键,驱动程序只需要报告该capability是否不受支持。如果后端具有一些供应商特定的capabilities,后端驱动程序还可以定义 供应商特定 键来支持capabilities。

备选方案

操作员仍然可以猜测应该在卷类型中设置哪些附加规格。操作员可以尝试查找卷类型附加规格的文档。最后,操作员可以深入研究不同的 Cinder 卷驱动程序代码,以弄清楚可能的附加类型。这些都不是可靠的解决方案。

数据模型影响

REST API 影响

新的端点 GET /v2/tenant/get_capabilities/ubuntu@lvm1_pool

{
  "namespace": "OS::Storage::Capabilities::ubuntu@lvm1_pool",
  "volume_backend_name": "lvm",
  "pool_name": "pool",
  "driver_version": "2.0.0",
  "storage_protocol": "iSCSI",
  "display_name": "Capabilities of Cinder LVM driver",
  "description":
   "These are volume type options provided by Cinder LVM driver, blah, blah.",
  "visibility": "public",
  "properties": {
   "thin_provisioning": {
      "title": "Thin Provisioning",
      "description": "Sets thin provisioning.",
      "type": "boolean"
    },
    "compression": {
      "title": "Compression",
      "description": "Enables compression.",
      "type": "boolean"
    },
    "vendor:compression_type": {
      "title": "Compression type",
      "description": "Specifies compression type.",
      "type": "string",
      "enum": [
        "lossy", "lossless", "special"
      ]
    },
    "replication": {
      "title": "Replication",
      "description": "Enables replication.",
      "type": "boolean"
    },
    "qos": {
      "title": "QoS",
      "description": "Enables QoS.",
      "type": "boolean"
    },
    "vendor:minIOPS": {
      "title": "Minimum IOPS QoS",
      "description": "Sets minimum IOPS if QoS is enabled.",
      "type": "integer"
    },
    "vendor:maxIOPS": {
      "title": "Maximum IOPS QoS",
      "description": "Sets maximum IOPS if QoS is enabled.",
      "type": "integer"
    },
    "vendor:minIOPS": {
      "title": "Burst IOPS QoS",
      "description": "Sets burst IOPS if QoS is enabled.",
      "type": "integer"
    },
    "vendor:persona": {
      "title": "Persona",
      "description": "I am something..." ,
      "default": "Generic",
      "enum": [
        "Generic",
        "ONTAP-legacy",
        "VMware",
        "OpenVMS",
        "HPUX",
        "WindowsServer",
        "Generic-ALUA",
        "Generic-legacy",
        "HPUX-legacy",
        "AIX-legacy",
        "EGENERA"]
    }
  }
}

这些 明确定义 的键在没有前缀的情况下指示,例如“qos”。这些是 Cinder 后端相当标准的基准键。我们期望大多数设备至少报告这些键的布尔值 True/False。

这些 供应商特定 键是可选的,并以供应商名称 + 冒号 (:) 的前缀指示。(例如,abcd:minIOPS)供应商驱动程序可以使用任何内容作为 供应商特定 键,但供应商名称前缀不应包含冒号,因为它会被下划线 (_) 自动替换。(abc:d -> abc_d)

让我们来看一下压缩功能

这是一个 明确定义 的键,我们期望设备报告 True 或 False,表明它们是否支持该功能。如果设备不仅支持该功能,而且可以配置,则选项键列在“options”部分下。这只是选项的 <key-name>,以及可以为其指定的有效值列表。注意,如果 options 键为空 ({}),则表示该capability键上没有可以设置的选项。

vendor:fireproof capability

这是一个 供应商特定 键,通过以“供应商名称”+“:”为前缀来指示。另外,请注意默认值为 True,并且没有选项。示例表明该设备始终是防火的,您无法更改它,它就是它本身。

thin_provisioning capability

这是一个 明确定义 的键,该键不被此特定供应商支持。因此,它默认为 False,并且不提供任何选项。

qos capability 描述了我们的一些边缘情况

此键是一个 明确定义 的键,可以通过选项进行高度自定义。明确定义的portion是capability是否受支持(再次是 True/False),再次,某些设备允许在同一设备上部署具有或不具有 QoS 的卷,您可以使用 <capability-key-name>=true|false 来指定它。

如果设备不支持此功能(即始终为 true),则省略此条目。

另一个关键部分是 供应商特定 键。对于那些允许设置其他特殊键来设置 QoS 的键,这些键名以列表形式提供,作为可以指定和设置为与服务质量相关的有效键。

vendor:persona 键是另一个很好的 供应商特定 capability 的例子

这非常类似于 QoS,并且同样,请注意我们只是提供有效值。

您会注意到数据结构遵循您将在附加规格中放置的设置。在这种特定情况下,除了基本键本身之外,没有其他选项,因此结构相当简单。

安全影响

API Impact 中提到的端点将仅通过 admin_api 策略提供。操作员或其他 OpenStack 服务将能够查询此信息。

通知影响

其他最终用户影响

Cinder 客户端示例

操作员希望为他们的 OpenStack 云定义新的卷类型。操作员将获取特定后端池的capabilities列表

首先获取服务列表

$ cinder service-list

使用列出的池之一,将其传递给 capabilities-list

$ cinder capabilities-list block1@lvm#pool

host_name: block1
volume_backend_name: lvm
pool_name: pool
driver_version: 2.0.0
storage_protocol: iSCSI

capabilities:

  compression:
    default: true
    options:
      compression: true, false
      compression_type: lossy, lossless, special

  thin_provisioning:
    default: false

  replication:
    default: false

  qos:
    default: true,
    options:
      qos: true, false
      vendor_keys:
        vendor:minIOPS,
        vendor:maxIOPS,
        vendor:burstIOPS

  vendor:fireproof:
    default: true
    options: {}

  vendor:persona:
    default: Generic
    options:
      Generic
      ONTAP-legacy
      VMware
      OpenVMS
      HPUX
      WindowsServer
      Generic-ALUA
      Generic-legacy
      HPUX-legacy
      AIX-legacy
      EGENERA

Horizon

Horizon 将更新为包含显示支持的capabilities,以便操作员可以在创建或编辑卷类型附加规格时选择和设置值。

如果卷类型没有与任何卷后端名称关联,则 Horizon 将没有要显示的附加规格键。管理员仍然可以输入他们自己的键/值对。这与当前流程相同。

如果驱动程序未发布 extra specs 字典,这将是任何未更新的驱动程序的情况,则不会执行任何客户端端过滤,并且行为将基本上恢复到当前情况,即 Horizon 中的管理员需要知道并输入键/值对,而没有额外的指导。

性能影响

其他部署者影响

开发人员影响

驱动程序维护者需要实现一个方法 get_capabilities。这应该从存储后端获取capabilities列表并将其转换为字典结构

{
  'driver_version:' '2.0.0',
  'storage_protocol:' iSCSI,
  'capabilities:' {
    'compression': {
      'default': True,
      'options': {
        'compression_type': ['lossy', 'lossless', 'special'],
        'compression': [True, False]
      }
    },
    'thin_provisioning': {
      'default': True,
      options: {
        'thin_provisioning': [True, False]
      }
    },
    'qos': {
      'default': True,
      options: {
        'qos': [True, False],
    }
   }
   'replication': {
     'default': True,
     options: {
       replication: [True, False]
     }
   }
 }

没有什么可以阻止供应商报告更少或更多的键,但以下内容被严格执行

  • 数据结构

  • capabilities 中的信息

  • 这些 明确定义 的capabilities。

  • 驱动程序版本

  • 存储协议

实现

负责人

主要负责人
其他贡献者

工作项

  • 向 Cinder API 添加新的端点。

  • 添加 RPC 调用。

  • 添加用于 get_capabilities 的新的卷管理器方法。

  • 使用 get_capabilities 方法更新 LVM 参考实现。

依赖项

关于 明确定义 capabilities 的决定将是 [2]。

测试

  • 单元测试

  • 最终,一旦所有驱动程序都支持它,进行 tempest 测试。

文档影响

更新 Cinder 开发者文档,以便驱动程序维护者参考如何从他们的卷驱动程序推送capabilities。

参考资料