Open Stack

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 (lbragstad at gmail.com) 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:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > __________________________________________________________________________
> >
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?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