Propose specification for oslo.limit library
This change explains the reasoning behind creating a new library to help other services consume unified limit information in keystone. Change-Id: Idcc719a5c92f865eabae76dd0b40c327380238b8
This commit is contained in:
parent
291b307d9d
commit
10919b43b1
|
@ -0,0 +1,8 @@
|
||||||
|
================
|
||||||
|
Rocky Release
|
||||||
|
================
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
|
||||||
|
*
|
|
@ -0,0 +1,127 @@
|
||||||
|
===============================
|
||||||
|
Proposed new library oslo.limit
|
||||||
|
===============================
|
||||||
|
|
||||||
|
This is a proposal to create a new library dedicated to enabling moreconsistent
|
||||||
|
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.
|
||||||
|
|
||||||
|
Alternatives library
|
||||||
|
====================
|
||||||
|
|
||||||
|
It looks like there was an existing library that attempted to solve some of
|
||||||
|
these problems, called `delimiter <https://github.com/openstack/delimiter>`_.
|
||||||
|
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.
|
||||||
|
|
||||||
|
Proposed adoption model/plan
|
||||||
|
============================
|
||||||
|
|
||||||
|
The `unified limit API
|
||||||
|
<https://docs.openstack.org/keystone/latest/admin/identity-unified-limits.html>`_
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
==============
|
||||||
|
|
||||||
|
Author(s)
|
||||||
|
---------
|
||||||
|
|
||||||
|
Who is leading the proposal of the new library? Must have at least two
|
||||||
|
individuals from the community committed to triaging and fixing bugs, and
|
||||||
|
responding to test failures in a timely manner.
|
||||||
|
|
||||||
|
Primary authors:
|
||||||
|
Lance Bragstad (lbragstad@gmail.com) lbragstad
|
||||||
|
XiYuan Wang (wangxiyuan@huawei.com) wxy
|
||||||
|
Other contributors:
|
||||||
|
<launchpad-id or None>
|
||||||
|
|
||||||
|
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
|
||||||
|
<https://etherpad.openstack.org/p/unified-limits-rocky-ptg>`_ for unified
|
||||||
|
limits. This is where we discussed the interaction between services and
|
||||||
|
keystone, ultimately agreeing on the inclusion of a library to handle quota
|
||||||
|
enforcement.
|
||||||
|
|
||||||
|
Revision History
|
||||||
|
================
|
||||||
|
|
||||||
|
.. list-table:: Revisions
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
|
* - Release Name
|
||||||
|
- Description
|
||||||
|
* - Rocky
|
||||||
|
- Introduced
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0
|
||||||
|
Unported License.
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
Loading…
Reference in New Issue