Domain Level Unified Limit Support

bp domain-level-limit

Currently Unified limit in Keystone is for project level. It can’t cover the domain level case.

Problem Description

In some case, especially for Public Cloud, an account in the cloud is usually a domain in Keystone. In the domain(account), the cloud provider allow the user to create his own projects, users, or roles. So of course, these resource should be handled by limit as well. From service provider sight, he needs the ability to control the cloud account’s limit. But Keystone now doesn’t support domain level limit. Suppose a case: There is a domain(account) has 3 projects, the service provider want to limit each project can create 10 vms, but the total vms in the domain should be less than 20. Keystone can’t handle this case currently.

Proposed Change

Database change

Create a new column called domain_id to limit table to store the limit’s domain_id proprety.

API change

Since the domain related APIs and resources are still alive in Keystone, API callers usually treat domain different with project. So for unified limit APIs, we’ll add domain_id as well.

Request: POST /limits

Add domain_id into request body. Either project_id or domain_id must be provided. The body is like:

Request Body

{
    "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"
        }
    ]
}

Request: GET /limits/{limit_id}

The response body will contain domain_id as well. If the project_id in the response body is None, it means this is a domain level limit.

Response Body

{
    "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
    }
}

Request: GET /limits

The response body is similar with GET /limits. Add the domain_id filter to query the specified limits.

Model change

Now both flat model and strict-two-level model are only for project level.

Non hierarchical model

Like Flat model, it is non hierarchical. So domain level limit in this kind of model is non hierarchical as well.

Hierarchical model

Like strict-two-level model, For this kind of model, Every project’s limit in a domain should not be larger than the domain’s limit.

Of course, The domain level be considered as one level In strict-two-level model currently, the depth of project should not greater than 2. Like:

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

Once domain level limit is supported, the structure will be:

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

Error Handler

The behavior for error handler will not be changed, It’ll keep the same with the enforcement model. See the detail in the enforcement part of strict-two-level-enforcement-model spec.

Backward compatibility

The unified limit feature is still experimental in Keystone and there is no customer currently. So there is not need to consider the backward compatibility now.

Alternatives

Database change

We can reuse the project_id column to store domain_id. At database layer, domain_id can be treat the same as project_id.

But this change would make the code much complex. Some code for dealing with project_id and domain_id would be added of which the user experience is not good.

Hierarchical model

For hierarchical model, we can treat domain level as the top level which does not consume the project level depth. Like:

Domain
  |
Project-level1
  |
Project-level2

But if so, the depth will be more than 2 which will break strict two concept. The strict-two-level-enforcement-model spec has a good explanation

Security Impact

N/A

Notifications Impact

N/A

Other End User Impact

This is a cloud admin feature. It doesn’t impact end user through APIs. If the end user is domain level, he may have limitation for cloud resource then.

Performance Impact

N/A

Other Deployer Impact

N/A

Developer Impact

N/A

Implementation

Assignee(s)

Primary assignee:

wangxiyuan<wangxiyuan@huawei.com>

Work Items

  • Update database schema

  • Update POST/GET /limits /limits/{limit_id} APIs.

  • Update limit model check function.

  • Update related docs.

Dependencies

N/A

Documentation Impact

Domain level limit support should be documented in admin guide.

References