Sending a follow up here since there has been some movement on this recently.
There is a nova specification up for review that goes through the work to consume unified limits out of keystone [0]. John and Jay have also been working through the oslo.limit integration, which is forcing us to think about the interface. There are a few patches up that take different approaches [1][2]. If anyone is still interested in helping out with this work, please don't hesitate to reach out. [0] https://review.openstack.org/#/c/602201/ [1] https://review.openstack.org/#/c/615180/ [2] https://review.openstack.org/#/q/project:openstack/oslo.limit+status:open On Tue, Sep 11, 2018 at 8:10 AM Lance Bragstad <lbrags...@gmail.com> wrote: > Extra eyes on the API would be appreciated. We're also close to the point > where we can start incorporating oslo.limit into services, so preparing > those changes might be useful, too. > > One of the outcomes from yesterday's session was that Jay and Mel (from > nova) were going to work out some examples we could use to finish up the > enforcement code in oslo.limit. Helping out with that or picking it up > would certainly help move the ball forward in nova. > > > > > On Tue, Sep 11, 2018 at 1:15 AM Jaze Lee <jaze...@gmail.com> wrote: > >> I recommend li...@unitedstack.com to join in to help to work forward. >> May be first we should the keystone unified limits api really ok or >> something else ? >> >> Lance Bragstad <lbrags...@gmail.com> 于2018年9月8日周六 上午2:35写道： >> > >> > 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 <jaze...@gmail.com> wrote: >> >> >> >> Lance Bragstad <lbrags...@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 <jaze...@gmail.com> wrote: >> >> >> >> >> >> On Stein only one service? >> >> >> Is there some methods to move this more fast? >> >> >> Lance Bragstad <lbrags...@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 <jaze...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
