Comment 0 for bug 1993288

Keystone has the ability to store and relay project specific limits (see [1]). The API (see [2]) provides a way for the admin to create limits for each project for the resources.
The feature is considered ready and even the API (via oslo_limts) can be changed as more and more projects adopt it and based on user feedback.

For how to use unified limits and adopt in a project a nice guideline is under [3].

Currently Nova (see [4]) and Glance (see [5]) partly implemented the usage of unified limits. It is still experimental.

Cinder checked this option but decided to wait till unified limits is more mature (see [7])

Pros (as I see):
* Common Openstack wide API for admins to define Limits for projects.
* Long term support for other enforcement models like hierarchies (as I see it is still not supported in oslo_limits, see [8]).

Cons (as I see):
* Keystone as bottleneck, for all operation an API req is needed (there is some cache in oslo_limit)
* How we can solve the concurency issue, it is now not a db_lock but we have to be sure that on the API level we handle concurrent resource usages.
* all resources must be first registered on Keystone API, otherwise the quota check/enforcement will fail.
* it is not yet ready (see the big warning on top of [1].

[1]: https://docs.openstack.org/keystone/latest/admin/unified-limits.html
[2]: https://docs.openstack.org/api-ref/identity/v3/#unified-limits
[3]: https://docs.openstack.org/project-team-guide/technical-guides/unified-limits.html
[4]: https://review.opendev.org/q/topic:bp%252Funified-limits-nova
[5]: https://review.opendev.org/q/topic:bp%252Fglance-unified-quotas
[6]: https://docs.openstack.org/keystone/latest/admin/unified-limits.html#strict-two-level
[7]: https://specs.openstack.org/openstack/cinder-specs/specs/zed/quota-system.html#unified-limits
[8]: https://opendev.org/openstack/oslo.limit/src/branch/master/oslo_limit/limit.py#L223-L240