Open Stack

Ben,

Ping me when you are planning on having this discussion if you think of 
it.  Since there is interest in this for Cinder I would like to try to 
be there.

Thanks!

Jay


On 9/7/2018 1:43 PM, Ben Nemec wrote:
> 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
>>
>
> __________________________________________________________________________ 
>
> 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