Open Stack

That would be great! I can break down the work a little bit to help
describe where we are at with different parts of the initiative. Hopefully
it will be useful for your colleagues in case they haven't been closely
following the effort.

# keystone

Based on the initial note in this thread, I'm sure you're aware of
keystone's status with respect to unified limits. But to recap, the initial
implementation landed in Queens and targeted flat enforcement [0]. During
the Rocky PTG we sat down with other services and a few operators to
explain the current status in keystone and if either developers or
operators had feedback on the API specifically. Notes were captured in
etherpad [1]. We spent the Rocky cycle fixing usability issues with the API
[2] and implementing support for a hierarchical enforcement model [3].

At this point keystone is ready for services to start consuming the unified
limits work. The unified limits API is still marked as stable and it will
likely stay that way until we have at least one project using unified
limits. We can use that as an opportunity to do a final flush of any
changes that need to be made to the API before fully supporting it. The
keystone team expects that to be a quick transition, as we don't want to
keep the API hanging in an experimental state. It's really just a safe
guard to make sure we have the opportunity to use it in another service
before fully committing to the API. Ultimately, we don't want to
prematurely mark the API as supported when other services aren't even using
it yet, and then realize it has issues that could have been fixed prior to
the adoption phase.

# oslo.limit

In parallel with the keystone work, we created a new library to aid
services in consuming limits. Currently, the sole purpose of oslo.limit is
to abstract project and project hierarchy information away from the
service, so that services don't have to reimplement client code to
understand project trees, which could arguably become complex and lead to
inconsistencies in u-x across services.

Ideally, a service should be able to pass some relatively basic information
to oslo.limit and expect an answer on whether or not usage for that claim
is valid. For example, here is a project ID, resource name, and resource
quantity, tell me if this project is over it's associated limit or default
limit.

We're currently working on implementing the enforcement bits of oslo.limit,
which requires making API calls to keystone in order to retrieve the
deployed enforcement model, limit information, and project hierarchies.
Then it needs to reason about those things and calculate usage from the
service in order to determine if the request claim is valid or not. There
are patches up for this work, and reviews are always welcome [4].

Note that we haven't released oslo.limit yet, but once the basic
enforcement described above is implemented we will. Then services can
officially pull it into their code as a dependency and we can work out
remaining bugs in both keystone and oslo.limit. Once we're confident in
both the API and the library, we'll bump oslo.limit to version 1.0 at the
same time we graduate the unified limits API from "experimental" to
"supported". Note that oslo libraries <1.0 are considered experimental,
which fits nicely with the unified limit API being experimental as we shake
out usability issues in both pieces of software.

# services

Finally, we'll be in a position to start integrating oslo.limit into
services. I imagine this to be a coordinated effort between keystone, oslo,
and service developers. I do have a patch up that adds a conceptual
overview for developers consuming oslo.limit [5], which renders into [6].

To be honest, this is going to be a very large piece of work and it's going
to require a lot of communication. In my opinion, I think we can use the
first couple iterations to generate some well-written usage documentation.
Any questions coming from developers in this phase should probably be
answered in documentation if we want to enable folks to pick this up and
run with it. Otherwise, I could see the handful of people pushing the
effort becoming a bottle neck in adoption.

Hopefully this helps paint the landscape of where things are currently with
respect to each piece. As always, let me know if you have any additional
questions. If people want to discuss online, you can find me, and other
contributors familiar with this topic, in #openstack-keystone or
#openstack-dev on IRC (nic: lbragstad).

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
[1] https://etherpad.openstack.org/p/unified-limits-rocky-ptg
[2] https://tinyurl.com/y6ucarwm
[3]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/strict-two-level-enforcement-model.html
[4]
https://review.openstack.org/#/q/project:openstack/oslo.limit+status:open
[5] https://review.openstack.org/#/c/600265/
[6]
http://logs.openstack.org/65/600265/3/check/openstack-tox-docs/a6bcf38/html/user/usage.html

On Thu, Sep 6, 2018 at 8:56 PM Jaze Lee <jazeltq at gmail.com> wrote:

> Lance Bragstad <lbragstad at gmail.com> 于2018年9月6日周四 下午10:01写道：
> >
> > I wish there was a better answer for this question, but currently there
> are only a handful of us working on the initiative. If you, or someone you
> know, is interested in getting involved, I'll happily help onboard people.
>
> Well，I can recommend some my colleges to work on this. I wish in S,
> all service can use unified limits to do quota job.
>
> >
> > On Wed, Sep 5, 2018 at 8:52 PM Jaze Lee <jazeltq at gmail.com> wrote:
> >>
> >> On Stein only one service?
> >> Is there some methods to move this more fast?
> >> Lance Bragstad <lbragstad at gmail.com> 于2018年9月5日周三 下午9:29写道：
> >> >
> >> > Not yet. Keystone worked through a bunch of usability improvements
> with the unified limits API last release and created the oslo.limit
> library. We have a patch or two left to land in oslo.limit before projects
> can really start using unified limits [0].
> >> >
> >> > We're hoping to get this working with at least one resource in
> another service (nova, cinder, etc...) in Stein.
> >> >
> >> > [0]
> https://review.openstack.org/#/q/status:open+project:openstack/oslo.limit+branch:master+topic:limit_init
> >> >
> >> > On Wed, Sep 5, 2018 at 5:20 AM Jaze Lee <jazeltq at gmail.com> wrote:
> >> >>
> >> >> Hello,
> >> >>     Does nova and cinder  use keystone's unified limits api to do
> quota job?
> >> >>     If not, is there a plan to do this?
> >> >>     Thanks a lot.
> >> >>
> >> >> --
> >> >> 谦谦君子
> >> >>
> >> >>
> __________________________________________________________________________
> >> >> 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
> >>
> >>
> >>
> >> --
> >> 谦谦君子
> >>
> >>
> __________________________________________________________________________
> >> 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
>
>
>
> --
> 谦谦君子
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180907/600402e4/attachment.html>