Open Stack

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