yahoo-eng-team team mailing list archive

[Lance Bragstad <lbragstad@xxxxxxxxx>]

Public bug reported:

The unified limits API introduced in Queens implemented a single
enforcement model called "flat". Since "flat" was the initial
enforcement model implementation, it was tightly coupled with the rest
of the logic for the limit API [0].

In the future, we plan to make enforcement models configurable so that
deployments can choose how they want limit enforcement to behave across
projects. This will be easier to do if we decouple the enforcement model
from the actual limit CRUD. The limit API will become simpler because
its won't have to worry about different characteristics of various
enforcement models. Instead, that logic can be encapsulated into a
single object, making it the sole responsibility of that object.

[0]
https://github.com/openstack/keystone/blob/ec338a3374000bcecf01acd9b4bce64f71d94a11/keystone/limit/core.py#L59-L63

** Affects: keystone
     Importance: Medium
         Status: Triaged


** Tags: limits

** Changed in: keystone
   Importance: Undecided => Medium

** Changed in: keystone
       Status: New => Triaged

** Tags added: limits

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1768572

Title:
  Limit API lacks abstraction for enforcement models

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  The unified limits API introduced in Queens implemented a single
  enforcement model called "flat". Since "flat" was the initial
  enforcement model implementation, it was tightly coupled with the rest
  of the logic for the limit API [0].

  In the future, we plan to make enforcement models configurable so that
  deployments can choose how they want limit enforcement to behave
  across projects. This will be easier to do if we decouple the
  enforcement model from the actual limit CRUD. The limit API will
  become simpler because its won't have to worry about different
  characteristics of various enforcement models. Instead, that logic can
  be encapsulated into a single object, making it the sole
  responsibility of that object.

  [0]
  https://github.com/openstack/keystone/blob/ec338a3374000bcecf01acd9b4bce64f71d94a11/keystone/limit/core.py#L59-L63

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1768572/+subscriptions