Open Stack

We had an extensive discussion of this in the keystone room today: 
https://etherpad.openstack.org/p/keystone-stein-unified-limits

We had a couple of Nova people in the room, so if anyone from other 
teams can take a look at the outcomes on the etherpad and let us know if 
there are any issues with the current plan for other projects that would 
be good.

On 09/10/2018 09:25 AM, Ben Nemec wrote:
> We had talked about Tuesday afternoon. I need to sync up with Lance and 
> figure out exactly when will work best.
> 
> On 09/08/2018 10:58 AM, Jay S Bryant wrote:
>> 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
>>
>>
>> __________________________________________________________________________ 
>>
>> 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