Taking the Nova work as an example, looking to add a basic flat enforcer
that meets Nova's needs.
The user of the Enforce provides a callback. You can see an example of
the callback in the unit tests:
def fake_callback(project_id, resources):
return {
"a": 5,
"b": 10,
"c": 0,
}
In the code where you want to check if you increase the amount of
resources that are being consumed, you can make this call:
enforcer = limit.Enforcer(fake_callback)
enforcer.enforce(project_id, {"a": 5})
The enforce function looks up the limits that apply for the given
project_id, uses the callback to count the current usage. The proposed
usage is then calculated be adding the delta and the current usage
together. This is compared to any limits that apply.
If you later want to check if you have races that mean you are
over your limit, you can do this call:
enforcer.enforce(project_id, {'a': 0})
Summary of key design points:
* single set of logic to enforce limits shared between all projects
that adopt unified limits
* interface should work for both flat and strict-two-level enforcement
* it is assumed that oslo.limit will control which type of enforcement
is being applied
* callback lists all resources that need counting
for the given project_id, in Nova this helps limit
the number of API calls made to placement
* allows to check if proposed additional usage means you are over
your limit, and also double check if the current usages means
you are over quota
* if the code is checking a resource where you do not have a
registered limit, we default to a limit of zero, i.e. no
resources can be created unless you set that registered limit
There will be an appropriate warning logged to help the operator
understand what needs to be setup in keystone.
This builds on various previous prototypes from:
Co-Authored-By: Lance Bragstad<lbragstad@gmail.com>
Co-Authored-By: wangxiyuan <wangxiyuan@huawei.com>
Change-Id: I294a922ea80af673291c991f07a4a203f25c289d
40ef2764a5