Cinder quotas have been a constant pain for operators and cloud users. Engineering should work on an alternative to the current quota mechanism that doesn´t seem to work as it should no matter how many fixes are submitted.

Cinder's current quota system is based on reservations and commits/rollbacks. When an operation that consumes quota is received by the API it validates the request and checks that there's enough quota to perform the operation and creates reservations to ensure that this quota is not consumed by other operations. Then when the operation finishes these reservations are committed as used resources or rolled back if the operation failed.

A new quota system will replace the existing one, where usage and resource tracking is no longer stored as counters in a database table (``quota_usages``) and instead is dynamically calculated on each quota check based on the resources that exist in the database.

Calculations will be simple counting for resources (e.g. ``snapshots``) or sum of values for sizes (e.g. ``gigabytes``).

In addition to dynamically calculating the resources, the new quota system will reduce the number of reservations and commits/rollbacks used by the code as much as possible, and will only use them for the specific cases were they are the only way to keep track of the resources while the operation is in progress.

The only operations that will require the use of reservations are extend, retype, and transfer.