领域级别统一限制支持

bp domain-level-limit

目前 Keystone 中的统一限制是项目级别的。它无法覆盖领域级别的情况。

问题描述

在某些情况下，特别是对于公有云，云中的一个账号通常在 Keystone 中是一个领域。在该领域（账号）中，云提供商允许用户创建自己的项目、用户或角色。因此，这些资源也应该受到限制的管理。从服务提供商的角度来看，他需要控制云账号的限制。但 Keystone 目前不支持领域级别限制。假设一种情况：有一个领域（账号）有 3 个项目，服务提供商希望限制每个项目可以创建 10 个虚拟机，但该领域中的虚拟机总数应少于 20 个。Keystone 目前无法处理这种情况。

提议的变更

数据库变更

在限制表中创建一个名为 domain_id 的新列，用于存储限制的 domain_id 属性。

API 变更

由于 domain 相关的 API 和资源在 Keystone 中仍然存在，API 调用者通常将 domain 与 project 区分对待。因此，对于统一限制 API，我们将添加 domain_id。

请求： POST /limits

将 domain_id 添加到请求体中。必须提供 project_id 或 domain_id 中的一个。请求体如下

请求体

{
    "limits":[
        {
            "service_id": "9408080f1970482aa0e38bc2d4ea34b7",
            "project_id": "3a705b9f56bb439381b43c4fe59dccce",
            "region_id": "RegionOne",
            "resource_name": "snapshot",
            "resource_limit": 5
        },
        {
            "service_id": "9408080f1970482aa0e38bc2d4ea34b7",
            "domain_id": "4d705b9f56bb296381b43c4fe59da34d",
            "resource_name": "volume",
            "resource_limit": 10,
            "description": "Number of volumes for domain 4d705b9f56bb296381b43c4fe59da34d"
        }
    ]
}

请求： GET /limits/{limit_id}

响应体也将包含 domain_id。如果响应体中的 project_id 为 None，则表示这是一个领域级别限制。

响应体

{
    "limit": {
        "resource_name": "volume",
        "region_id": null,
        "links": {
            "self": "http://10.3.150.25/identity/v3/limits/25a04c7a065c430590881c646cdcdd58"
        },
        "service_id": "9408080f1970482aa0e38bc2d4ea34b7",
        "project_id": null,
        "domain_id": "3a705b9f56bb439381b43c4fe59dccce",
        "id": "25a04c7a065c430590881c646cdcdd58",
        "resource_limit": 11,
        "description": null
    }
}

请求： GET /limits

响应体与 GET /limits 类似。添加 domain_id 过滤器以查询指定的限制。

模型变更

现在，flat 模型和 strict-two-level 模型都仅适用于项目级别。

非分层模型

与 Flat 模型一样，它是非分层的。因此，在这种模型中，领域级别限制也是非分层的。

分层模型

与 strict-two-level 模型一样，对于这种模型，领域中的每个项目的限制不应大于该领域的限制。

当然，在 strict-two-level 模型中，领域级别被视为一个级别。目前，项目的深度不应大于 2。例如

Project(level-1)
     |
Project(level-2)

一旦支持领域级别限制，结构将变为

Domain(level-1)
  |
Project(level-2)

错误处理

错误处理的行为不会改变，它将与强制模型保持一致。有关详细信息，请参阅 strict-two-level-enforcement-model 规范的 强制 部分。

向后兼容性

统一限制功能在 Keystone 中仍然是实验性的，目前没有客户。因此，现在无需考虑向后兼容性。

备选方案

数据库变更

我们可以重用 project_id 列来存储 domain_id。在数据库层，domain_id 可以与 project_id 相同。

但是，这种更改会使代码更加复杂。将添加一些用于处理 project_id 和 domain_id 的代码，这会降低用户体验。

分层模型

对于分层模型，我们可以将领域级别视为顶级，不占用项目级别的深度。例如

Domain
  |
Project-level1
  |
Project-level2

但是，如果这样，深度将超过 2，这将破坏 strict two 的概念。strict-two-level-enforcement-model 规范有一个很好的 解释

安全影响

N/A

通知影响

N/A

其他最终用户影响

这是一个云管理员功能。它不会通过 API 影响最终用户。如果最终用户是领域级别，他可能会受到云资源限制。

性能影响

N/A

其他部署者影响

N/A

开发人员影响

N/A

实现

负责人

主要负责人

wangxiyuan<wangxiyuan@huawei.com>

工作项

  • 更新数据库模式

  • 更新 POST/GET /limits /limits/{limit_id} API。

  • 更新限制模型检查函数。

  • 更新相关文档。

依赖项

N/A

文档影响

领域级别限制支持应在管理员指南中记录。

参考资料

  • OpenStack 公有云 WG 需求