RFE: ProjectClaims should support multiple resources

[Lance Bragstad]

The initial design of the oslo.limit library broke the concept of usage enforcement into two different things. One was the "claim" and the other was "enforcement". The claim is just a mapping of the resource name and the quantity of things being asked for in the request wrapped into an object that could be passed to the enforcer. The enforcement is, in theory, generic enough to just accept claim objects.

Up to this point, claims are a one-to-one mapping of resource -> quantity. Likewise, the enforcer only accepts a single claim, as opposed to multiple claims.

It became apparent in a discussion today with nova [0] that support for enforcing multiple claims at the same time should be implemented. A good example of why this is needed is calculating usage for instances or servers. This is because nova (and possibly other services) calculate usage checks based on cores, memory, and total instances per project (these are the claims). If any one of these claims causes the project to exceed its limit, an exception should be raised. If claims are kept as a one-to-one mapping between resource names and quantity, then we'll be forcing services to build multiple claims and enforce them individually, which would be messy.

An alternative would be to make claim objects smarter by supporting multiple resource to quantity mappings in a single claim. This improves developer experience because they only have to build one claim before passing it to the enforcer. It also doesn't require the enforcer implementation to know about more than one claim.

An example of what this might look like as someone using oslo.limit would be [1].

[0] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-09-05.log.html
[1] https://gist.github.com/lbragstad/69d28dca8adfa689c00b272d6db8bde7#file-multiple-resource-single-claim-py-L33-L42

[OpenStack Infra (hudson-openstack)]

Change abandoned by Lance Bragstad (<email address hidden>) on branch: master
Review: https://review.openstack.org/600266
Reason: Putting this on the back burner until we discuss it further at the PTG/forum. We can restore if we decide this is still the direction we'd like to go.