改进 Stein 中的份额和后端能力

https://blueprints.launchpad.net/manila/+spec/storage-proto-enhancement

https://blueprints.launchpad.net/manila/+spec/make-share-shrinking-support-a-capability

Manila 的后端存储驱动程序提供广泛的功能。这些功能的差异允许云管理员向最终用户提供存储服务目录。

有时后端功能非常特定于存储系统，对于 manila 或最终用户来说是不透明的——它们为相关的存储驱动程序提供编程指令，以便在创建份额或操作份额期间执行某些操作。云管理员通过驱动程序文档了解 opaque capabilities（不透明功能），并将这些功能配置为份额类型中的 scoped extra-specs（作用域限定的额外规格）（例如：hpe3par:nfs_options）。manila 调度器在寻找合适的后端来配置份额时，会忽略作用域限定的额外规格。

Manila 中有一些后端功能对调度器 有 影响。为了我们的理解，我们称这些为 non-opaque capabilities（非不透明功能）。这些功能的文档在这里 [1]，份额后端功能支持分类在这里 [2]。所有非不透明功能都可以用作份额类型中的 non-scoped extra-specs（非作用域限定的额外规格）。非不透明功能有三种类型

• 与特定后端存储系统驱动程序相关的能力：例如，huawei_smartcache，这些功能被调度器的功能过滤器（以及部署者定义的任何自定义过滤器）考虑。这些功能通过 scheduler-stats API 报告，但是，其他 manila API 不依赖于它们。

• 公共能力，不可见于租户：manila 社区已经标准化了一些跨平台能力，例如 thin_provisioning（精简配置）、dedupe（去重）、compression（压缩）、qos（服务质量）、ipv6_support（IPv6 支持）和 ipv4_support（IPv4 支持）。这些选项的值对任何 manila API 都没有影响，但是，它们可以对 manila 服务本身表示某些含义。例如，当后端支持 thin_provisioning 时，调度服务执行过度配置，如果后端未将 ipv6_support 报告为 True，则 share-manager 服务在调用存储驱动程序以允许/拒绝访问规则之前会删除 IPv6 访问规则。

  虽然这些功能不可见于租户，但管理员可以将它们用作份额类型中的额外规格，并且调度器将在各种过滤器中匹配这些功能，包括 manila 包含的功能过滤器。

• 可见于租户的公共能力：某些功能会影响通过 manila API 公开的功能。例如，并非所有后端都支持快照，即使支持，它们可能也不支持 所有 快照操作。例如，snapshot_support（快照支持）、create_share_from_snapshot_support（从快照创建份额支持）、revert_to_snapshot_support（还原到快照支持）、mount_snapshot_support（挂载快照支持）和 replication_type（复制类型）等。对这些额外规格的支持决定了用户是否能够使用 manila 执行某些控制平面操作。例如，CEPHFS 后端可以将 snapshot_support 报告为 True，允许最终用户调用快照 API，但是，CEPHFS 快照不能被驱动程序用于创建新的份额，因此它将 create_share_from_snapshot_support 报告为 False。这种报告允许云管理员创建一个支持快照但不创建快照的份额类型。当用户使用这样的份额类型并且他们的份额在 CEPH 集群上创建时，他们无法成功调用快照 API，因为份额类型指定该功能对于该特定份额已被禁用。

可见于租户的功能有助于 manila 验证请求并快速拒绝无法满足的请求。它们还有助于设定用户对某些失败的期望。例如，如果份额类型上将 snapshot_support 设置为 False，由于用户可以看到这一点，他们将不会调用创建快照 API，即使他们这样做，他们也会更好地理解 HTTP 400（和错误消息）。

同步失败可以通过自动化以及手动与 manila 交互的最终用户来处理。因此，在尽可能大的程度上，必须执行可以在 API 中执行的所有验证，因为尽早快速失败比异步失败更好。

异步失败可能更难应对。通过用户消息 [3]，租户可以检查异步失败的原因。但是，并非所有用户消息都可以由最终用户操作。

问题描述

本规范侧重于两个问题领域：份额的缩小和存储协议

缩小份额

共享文件系统旨在具有弹性。但是，并非所有存储系统都支持减小分配的文件系统的大小。考虑 manila 部署了不支持份额缩小的后端的场景。当用户尝试缩小在所述后端上配置的份额时，调用会到达 share-manager 进程并在驱动程序处失败，并出现 NotImplementedError。失败的结果导致份额的状态更改为 shrinking_error。也没有用户消息 [4]。即使份额本身没有以任何方式被操作，份额上的状态也会使其不可能对其执行任何其他操作。通常，用户必须联系云管理员才能从这种状态更改中恢复。

支持的存储协议

当前有一个配置选项 enabled_share_protocols，该选项由 manila API 服务用于验证用户的请求是否可以接受进行调度。如果此选项配置错误，我们预计会发生调度失败（参见 Bug 1783736 [5]）。用户无法知道已配置哪些存储协议以及给定部署中支持哪些协议。驱动程序本身可能支持一个或多个存储协议，并将这些协议报告给调度程序。我们几年前在 manila 中引入了功能列表 [6]。但是，支持多种协议的驱动程序正在向调度程序报告一个融合字符串（例如：NFS_CIFS）。

用例

• 用户必须能够在预先确定是否可以缩小份额

• 如果用户尝试缩小不支持缩小的份额，则用户必须收到同步 API 失败。

• 云管理员必须能够将份额类型上的额外规格配置为支持的存储协议。

• 用户必须能够通过份额类型确定 manila 部署中支持哪些存储协议。

• UI 应该能够过滤通过份额类型支持和启用的份额协议，反之亦然。

提议的变更

• 将引入一个新的公共能力，称为 shrink_support。基本驱动程序将确定是否实现了 shrink_share() 接口，并相应地报告 shrink_support 功能。

• 云管理员可以将 shrink_support 配置为份额类型中的额外规格。此额外规格将可见于租户，并且可以具有三个值之一：True、False 或 legacy（保留值）。

• 如果额外规格的值设置为 True，则调度器只会匹配报告 shrink_support=True 的后端。如果额外规格的值设置为 False 或 legacy，则份额可以安排到可能支持或不支持缩小份额的后端。

• 如果额外规格的值设置为 False，manila 将设置一个布尔标志（也称为 shrink_support）在份额对象上设置为 False。shrink API 检查此标志，如果值为 False，则会立即禁止缩小。

• 如果额外规格的值设置为 legacy，则调度器会忽略该功能并允许将份额配置到任何后端（由所有其他因素过滤和加权）。成功调度和创建份额后，将确定 shrink_support 的实际值，并由 share-manager 进程在份额上设置。

注意

额外规格值 legacy 保留了向后兼容性，以安排具有预先存在的份额类型的份额。请参阅 升级影响 部分，了解有关此提案的更多讨论。

• 管理员只能将 shrink_support 的值设置为布尔表达式。因此，他们将被阻止将值设置为保留值 legacy。

• 云管理员已经能够将 storage_protocol 配置为额外规格。此额外规格将变得可见于租户。如果管理员未配置此额外规格，则其默认值为 '*'，表示允许创建所有存储协议的份额。此额外规格的值可以是单个协议或列表形式，例如：<in> NFS <in> CIFS。

• 如果存在额外规格 storage_protocol 且未设置为 '*'，则 API 将验证正在创建的份额的请求协议是否受份额类型支持。

• UI 将被修改为解析所选份额类型并在创建份额表单的下拉列表中填充允许的协议。

• 报告多种协议的驱动程序将被更新为将它们报告为功能列表而不是字符串。

• 基本驱动程序将评估 [DEFAULT]/enabled_share_protocols 并将此列表与驱动程序代码报告的功能相交，以向调度程序报告驱动程序支持的正确协议/协议。

备选方案

不将 shrink_support 作为功能实现的一个替代方案是使用 API 策略（share:shrink）禁用份额缩小 API。但是，如果云具有多个后端，其中一个或多个支持缩小份额，而其他后端不支持，则无法使用此机制。

用户今天无法发现他们可以使用哪些存储协议。我们可以通过期望云管理员在 manila 之外的范围内传达支持的内容来接受这种情况。这种策略对于小型部署（最终用户和云管理员之间存在紧密沟通）可能有效。对于许多其他人来说，这种不便可能会令人恼火，例如，考虑一个希望发现功能并在任何 OpenStack 云上运行的跨云应用程序。

数据模型影响

manila.db.sqlalchemy.models.Share 模型将被修改为包含一个可为空的字段，称为 shrink_support。

升级影响

将不会迁移数据来填充现有份额上的 shrink_support 功能字段。此字段的初始值将为 null。当用户尝试缩小其 shrink_support 属性设置为 NULL 的份额时，API 的工作方式将与今天相同，行为不会发生变化，无论后端是否真的可以缩小份额。

在 share-manager 服务中，如果驱动程序引发 NotImplementedError，则该字段设置为 False 并生成用户消息。份额的状态将被设置为 shrinking_error。重置份额的状态后，如果用户尝试再次缩小相同的份额，API 将能够防止它，因为 shrink_support 已被适当地确定。如果 share-manager 服务未检测到 NotImplementedError，则 shrink_support 字段将被设置为 True。

所有现有的份额类型都将被更新为包含额外规格 shrink_support，其值设置为 legacy。此升级影响将在管理员文档和发行说明中明确说明。通过设置此额外规格，我们保留了向后兼容性。如果其值为 legacy，manila 调度器将忽略 shrink_support 功能。如果用户使用这样的份额类型来创建份额，则会在调度服务中记录一条警告消息，建议管理员覆盖 legacy 值以增强用户体验。

份额的 shrink_support 属性在驱动程序在份额创建后通过驱动程序已知的功能确定。如果云管理员不更改从 legacy 的值，他们的部署将继续提供糟糕的用户体验。用户在创建份额之前不知道是否可以缩小份额。如果相同的 legacy 份额类型匹配两个后端：一个支持缩小份额，另一个不支持，体验会进一步恶化。用户会看到有些份额是可缩小的，而其他份额即使使用相同的 legacy 份额类型也是不可缩小的。

REST API 影响

请注意我们 API 参考 中这些 API 的当前状态。

创建和管理份额 API:

POST /v2/{tenant_id}/shares
POST /v2/{tenant_id}/shares/manage

对请求模式/标头/授权/端点的更改：无

对 API 行为/响应模式/标头/授权的更改

响应模式

{
    "share": {
        ...
        "shrink_support": true,
        ...
    }
}

API 将根据租户可见的额外规格 shrink_support 的设置，将其 shrink_support 属性设置为 True。如果该规格被设置为可以评估为 True 的值。如果 shrink_support 额外规格未配置，或者其值被设置为 False，则 share 上的 shrink_support 属性将被设置为 False。

注意

请参阅 升级影响，以了解现有 share 类型将如何处理。

API 将评估请求的协议是否存在于 share 类型使用的 storage_protocol 额外规格中。如果不存在，将向请求者发送 HTTP 400 错误，提示他们正在使用不受支持的协议。

缩小 share API:

POST /v2/{tenant_id}/shares/{share_id}/action

对请求模式/标头/授权/端点的更改：无

对 API 行为/响应模式/标头/授权的更改

在新的 API 版本中，将评估 share 对象的 shrink_support 属性，如果缩小操作不允许，将向请求者返回 HTTP 400 错误。由于此操作如果允许执行一定会失败，因此为了提供更好的用户体验，API 向后兼容性将不会被保留。

其他 API:

GET /v2/{tenant_id}/shares
GET /v2/{tenant_id}/shares/detail
GET /v2/{tenant_id}/shares/{share_id}
PUT /v2/{tenant_id}/shares/{share_id}

上述所有 API 都将在新的 API 版本中包含响应模式更改，以包含 shrink_support。

share 类型 API

POST /v2/{tenant_id}/types
POST /v2/{tenant_id}/types/{share_type_id}/extra_specs

已经禁止对一系列租户可见的通用额外规格使用非布尔值。 shrink_support 将被添加到此列表中。

安全影响

无

通知影响

LP 1783736 的修复 [4] 将添加一个通知，用于可能异步失败的 share 缩小操作。

其他最终用户影响

无

性能影响

无

其他部署者影响

有关部署者操作，请参阅 升级影响，了解此功能发布后的操作。

开发人员影响

无

驱动程序影响

作为此工作的一部分，driver capability storage_protocol 将被更改，以清理对多种协议的支持。它将从下划线分隔的字符串转换为 capability 列表。

实现

负责人

主要负责人

gouthamr

工作项

• 引入 shrink_support capability。修改创建/管理 share API 和其他 share API view builder。添加数据库迁移以引入 share capability 属性。添加基础 driver 实现以检测缩小 share 的支持。

• 引入 storage_protocol 租户可见的额外规格，修改 driver 报告

• 在 python-manilaclient 和 manila-ui 中添加对 shrink_support 的支持

• 在 python-manilaclient 和 manila-ui 中添加对 storage_protocol 的支持

• 为这两个更改添加 tempest 测试

依赖项

无

测试

将根据社区标准添加/维护单元测试覆盖率。将修改/添加 tempest 测试以覆盖新的 API 更改。share 缩小测试现在将创建一个将 shrink_support 设置为 True 的新的 share 类型，以测试缩小 share。

文档影响

以下 OpenStack 文档将更新以反映此更改

• OpenStack 用户指南：将改进 Capabilities 文档

• OpenStack 管理员指南：将记录 share 类型更改并重新强调升级影响（发布说明将详细包含影响和操作）。

• OpenStack API 参考：将记录新的 API

• Manila 开发者参考：预计没有新的文档

• OpenStack 安全指南：预计没有新的文档

参考资料

[1]

Rocky 版本中的 Capabilities 和 Extra-Specs https://docs.openstack.org/manila/rocky/admin/capabilities_and_extra_specs.html

[2]

Rocky 版本中的 Manila share 功能支持映射 https://docs.openstack.org/manila/rocky/admin/share_back_ends_feature_support_mapping.html

[3]

用户消息功能规范 https://specs.openstack.org/openstack/manila-specs/specs/pike/user-messages.html

[4] (1,2)

share 管理器中没有用户消息缩小错误 https://bugs.launchpad.net/manila/+bug/1802424

[5]

调度器不筛选存储协议 https://bugs.launchpad.net/manila/+bug/1783736

[6]

Manila 调度器中的 Capability 列表 https://review.openstack.org/#/c/260054/