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
