Excerpts from Lance Bragstad's message of 2018-03-12 11:45:28 -0500: > I missed the document describing the process for this sort of thing [0]. > So I'm back tracking a bit to go through a more formal process. > > [0] > http://specs.openstack.org/openstack/oslo-specs/specs/policy/new-libraries.html > > # Proposed new library oslo.limit > > This is a proposal to create a new library dedicated to enabling more > consistent quota and limit enforcement across OpenStack. > > ## Proposed library mission > > Enforcing quotas and limits across OpenStack has traditionally been a > tough problem to solve. Determining enforcement requires quota knowledge > from the service along with information about the project owning the > resource. Up until the Queens release, quota calculation and enforcement > has been left to the services to implement, forcing them to understand > complexities of keystone project structure. During the Pike and Queens > PTG, there were several productive discussions towards redesigning the > current approach to quota enforcement. Because keystone is the authority > of project structure, it makes sense to allow keystone to hold the > association between a resource limit and a project. This means services > still need to calculate quota and usage, but the problem should be > easier for services to implement since developers shouldn't need to > re-implement possible hierarchies of projects and their associated > limits. Instead, we can offload some of that work to a common library > for services to consume that handles enforcing quota calculation based > on limits associated to projects in keystone. This proposal is to have a > new library called oslo.limit that fills that need. > > ## Consuming projects > > The services consuming this work will be any service that currently > implements a quota system, or plans to implement one. Since keystone > already supports unified limits and association of limits to projects, > the implementation for consuming projects is easier. instead of having > to re-write that implementation, developers need to ensure quota > calculation to passed to the oslo.limit library somewhere in the API's > validation layer. The pattern described here is very similar to the > pattern currently used by services that leverage oslo.policy for > authorization decisions. > > ## Alternative libraries > > It looks like there was an existing library that attempted to solve some > of these problems, called delimiter [1]. It looks like delimiter could > be used to talk to keystone about quota enforcement, where as the > existing approach with oslo.limit would be to use keystone directly. > Someone more familiar with the library (harlowja?) can probably shed > more light on it's intended uses (I couldn't find much documentation), > but the presentation linked in a previous note was helpful. > > [1] https://github.com/openstack/delimiter > > ## Proposed adoption model/plan > > The unified limit API [2] in keystone is currently marked as > experimental, but the keystone team is actively collecting and > addressing feedback that will result in stabilizing the API. > Stabilization changes that effect the oslo.limit library will also be > addressed before version 1.0.0 is released. From there, we can look to > incorporate the library into various services that either have an > existing quota implementation, or services that have a quota requirement > but no implementation. > > This should help us refine the interfaces between services and > oslo.limit, while providing a facade to handle complexities of project > hierarchies. This should enable adoption by simplifying the process and > making it easier for quota to be implemented in a consistent way across > services. > > [2] > https://docs.openstack.org/keystone/latest/admin/identity-unified-limits.html > > ## Reviewer activity > > At first thought, it makes sense to model the reviewer structure after > the oslo.policy library, where the core team consists of people not only > interested in limits and quota, but also people familiar with the > keystone implementation of the unified limits API. > > ## Implementation > > ### Primary Authors: > > Lance Bragstad ([email protected]) lbragstad > You? > > ### Other contributors: > > You? > > ## Work Items > > * Create a new library called oslo.limit > * Create a core group for the project > * Define the minimum we need to enforce quota calculations in oslo.limit > * Propose an implementation that allows services to test out quota > enforcement via unified limits > > ## References > > Rocky PTG Etherpad for unified limits: > https://etherpad.openstack.org/p/unified-limits-rocky-ptg > > ## Revision History > > Introduced in Rocky > > On 03/07/2018 11:55 PM, Joshua Harlow wrote: > > So the following was a prior effort: > > > > https://github.com/openstack/delimiter > > > > Maybe just continue down the path of that and/or take that whole repo > > over and iterate (or adjust the prior code, or ...)?? Or if not that's > > ok to, ya'll get to decide. > > > > https://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal > > > > > > Lance Bragstad wrote: > >> Hi all, > >> > >> Per the identity-integration track at the PTG [0], I proposed a new oslo > >> library for services to use for hierarchical quota enforcement [1]. Let > >> me know if you have any questions or concerns about the library. If the > >> oslo team would like, I can add an agenda item for next weeks oslo > >> meeting to discuss. > >> > >> Thanks, > >> > >> Lance > >> > >> [0] https://etherpad.openstack.org/p/unified-limits-rocky-ptg > >> [1] https://review.openstack.org/#/c/550491/ > >> > >> > >> > >> __________________________________________________________________________ > >> > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> [email protected]?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > > > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
+1 to the plan. It would be good to have this added to the oslo-specs repo so it's easier to find in the future. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
