Refactor pluggable enforcement models

Bug #1835104 reported by Lance Bragstad
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

The oslo.limit library exposes an Enforcer object for services to consume unified limits out of keystone. This Enforcer is responsible for understanding which enforcement model to use (configured in keystone and exposed via keystone API) and applying the enforcement properties of the library internally so that services don't have to.

The current implementation loads enforcement models as separate objects from the Enforcer. The model logic isn't built into the Enforcer object directly because we want it to be easy to add new models without changing the Enforcer. Conversely, the enforcement model objects need a lot of the same information that the Enforcer already has. This leads to sometimes awkward situations where we're passing the same data across two different objects.

We should investigate ways to improve this relationship and boundaries between enforcement model objects and the Enforcer object. The main goal is to make it easy to add new enforcement models without requiring changes to the Enforcer, but reduce the amount of duplicate information passed around internally.

This was discussed during a group code review of the oslo.limit implementation [0].


description: updated
Colleen Murphy (krinkle)
Changed in oslo.limit:
status: New → Triaged
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers