Open Stack

I will also note that I had an oslo.limit topic on the Oslo PTG 
schedule: https://etherpad.openstack.org/p/oslo-stein-ptg-planning

I don't know whether anybody from Jaze's team will be there, but if so 
that would be a good opportunity for some face-to-face discussion. I 
didn't give it a whole lot of time, but I'm open to extending it if that 
would be helpful.

On 09/07/2018 01:34 PM, Lance Bragstad wrote:
> 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 
> <mailto:jazeltq at gmail.com>> wrote:
> 
>     Lance Bragstad <lbragstad at gmail.com <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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
>