每个共享类型支持配额¶

蓝图: https://blueprints.launchpad.net/manila/+spec/support-quotas-per-share-type

目前，Manila 中的配额可以按租户和用户配置。它们允许管理员设置共享数量、快照数量或项目空间的千兆字节数，并允许项目成员在这些限制范围内使用资源。此规范描述了当前配额方案的扩展：除了共享数量的总体配额外，管理员还具有为给定共享类型定义共享数量配额的附加选项。此功能类似于 Cinder 为卷类型配额提供的功能。

问题描述¶

配额旨在帮助管理员控制可用资源的配置，例如共享数量或共享在配置的后端上占用的空间。虽然 Manila 支持配额，但当前的配额方案并未考虑共享类型。考虑到具有多个后端（通过不同的共享类型访问）的设置，管理员因此无法控制各个后端上的资源消耗。

用例¶

在具有多种共享类型的设置中，每个共享类型的配额将允许资源提供商更好地控制配置的资源。

提议的变更¶

该提案是在项目和用户配额的基础上添加每个共享类型的配额。当请求资源时，首先检查共享类型特定的配额。如果此检查通过，则根据该资源的项目的/用户的配额验证请求。将仅能为每个项目设置共享类型配额，而不能为单个项目中的用户设置配额。这是有意限制，以避免创建另一个配额层（第三层），该层只有在我们需要为与单个项目相关的用户设置不同的共享类型配额时才有用。

备选方案¶

另一种方法是使所有共享类型私有，要求用户为他们想要访问的每个共享类型创建一个新的租户，然后授予相应租户的访问权限。当共享类型数量增加或针对其他项目和资源的配额方案遵循相同方法时，这将对用户来说变得不切实际。

另一种可能的解决方案是移植 Cinder 的实现。Cinder 不会创建额外的配额层，而是为每个创建的卷类型创建额外的配额资源，并使用以下模板命名它们

%RESOURCE_NAME%_%VOLUME_TYPE_NAME%

但是这种方法有两个不便之处

“quota-show”命令的响应随着每个新的共享/卷类型的创建而增长

新的共享类型相关的配额资源的名称可能根据共享类型的名称而令人困惑。例如，共享类型“default”和“shares”配额资源将产生一个名为“shares_default”的额外配额资源，与现有的“shares”项目配额资源并行，这对于理解来说并不是很直观。

数据模型影响¶

新的共享类型配额将拥有自己的数据库模型，类似于现有数据库模型，该模型用于“用户”配额，并与“项目”配额具有相同的关系。因此，它的行为将与“用户配额”完全相同。我们将拥有以下结构

digraph quotas { center=true; node_pr [label = "项目配额", shape = ellipse, width = 2.2]; node_prs[label = "<f0> PROJECT_1|<f1> PROJECT_2|<f2> \.\.|<f3> PROJECT_N", shape = record, fontsize = 10]; "node_prs":f0 -> "node_pr" [dir=back]; "node_prs":f1 -> "node_pr" [dir=back]; "node_prs":f3 -> "node_pr" [dir=back]; node_u [label = "用户配额", shape = ellipse, width = 2.2]; node_us[label = "<f0> USER_1|<f1> USER_2|<f2> \.\.|<f3> USER_N", shape = record, fontsize = 10]; "node_u" -> "node_us":f0; "node_u" -> "node_us":f1; "node_u" -> "node_us":f3; node_st [label = "共享类型配额", shape = ellipse, width = 2.2]; node_sts[label = "<f0> ST_1|<f1> ST_2|<f2> \.\.|<f3> ST_N", shape = record, fontsize = 10]; "node_st" -> "node_sts":f0; "node_st" -> "node_sts":f1; "node_st" -> "node_sts":f3; "node_pr" -> "node_u"; "node_pr" -> "node_st"; }

REST API 影响¶

四个配额 API 中的三个 (3) 将被更改 - ‘update’、‘delete’ 和 ‘get’ API。‘defaults’ 将保持不变，并返回项目默认配额，因为它们将是每个共享类型的默认值。所有三个 API 都将开始处理额外的 ‘share_type’ GET 参数，该参数将与现有的 ‘user_id’ 参数互斥。响应结构将保持不变，唯一的例外是配额 ‘share_networks’ 将不存在于 ‘quota-show’ 响应体中，因为这种类型的配额在共享类型的情况下没有意义。此外，将无法为共享类型设置/更新此配额。新的 ‘share_type’ 参数应该能够接受共享类型的名称和 UUID。API 更改需要微版本更新。旧的微版本将表现得像以前一样。

获取配额

URL: /quota-sets?share_type=%name_or_id%
方法：GET

响应体

{
    'quota_set': {
        'shares': -1,
        'gigabytes': -1,
        'snapshots': -1,
        'snapshot_gigabytes': -1,
    }
}

注意

由于它是用户/项目配额，响应中不存在 ‘share_networks’ 配额。

删除配额
- URL: /quota-sets?share_type=%name_or_id%
- 方法：DELETE

更新配额

URL: /quota-sets?share_type=%name_or_id%
方法：PUT

JSON body

{
    'quotas': {
        'shares': -1,
        'gigabytes': -1,
        'snapshots': -1,
        'snapshot_gigabytes': -1,
    }
}

驱动程序影响¶

无。

安全影响¶

无。

通知影响¶

无。

其他最终用户影响¶

Manila 客户端将获得 ‘quota-update’、‘quota-show’ 和 ‘quota-delete’ 命令的新可选 ‘–share-type’ 参数，因此修改后的客户端版本将是

$ quota-update ... [--share-type <name_or_id>] ... <tenant_id>
$ quota-show ... [--share-type <name_or_id>] ... --tenant <tenant_id>
$ quota-delete ... [--share-type <name_or_id>] ... --tenant <tenant_id>

当省略 ‘–share-type’ 参数时，将更新项目配额，就像现在一样。如果传递了 ‘–share-type’ 参数，将为指定的共享类型设置相应资源的配额。

性能影响¶

额外的配额使用量计算层将在一定程度上减慢速度。

其他部署者影响¶

创建新的共享类型时，新共享类型的初始配额将是项目配额。因此，对于新租户，如果希望它们与项目配额不同，则必须为共享类型设置初始配额。

开发人员影响¶

消耗配额的新功能开发人员需要在 ‘reserve’、‘commit’ 和 ‘rollback’ 配额命令中提供额外的 “share_type_id” 参数。底层的数据库层将自动处理这两个配额层。

实现¶

负责人¶

主要负责人

vponomaryov ( vponomaryov@mirantis.com )

工作项¶

服务器端 API 变更
Manila 客户端变更
Manila UI 变更

依赖项¶

无。

测试¶

‘manila’、‘python-manilaclient’ 和 ‘manila-ui’ 项目中的单元测试
‘manila’ 和 ‘python-manilaclient’ 项目中的功能测试

文档影响¶

管理员指南：添加 ‘update-quota’、‘quota-show’ 和 ‘quota-delete’ 命令的新 ‘–share-type’ 参数。
devref：反映提议的变更

支持每个共享类型的配额

manila-specs 0.0.1.dev209

页面内容