Open Stack

Sending a follow up here since there has been some movement on this
recently.

There is a nova specification up for review that goes through the work to
consume unified limits out of keystone [0]. John and Jay have also been
working through the oslo.limit integration, which is forcing us to think
about the interface. There are a few patches up that take different
approaches [1][2].

If anyone is still interested in helping out with this work, please don't
hesitate to reach out.

[0] https://review.openstack.org/#/c/602201/
[1] https://review.openstack.org/#/c/615180/
[2]
https://review.openstack.org/#/q/project:openstack/oslo.limit+status:open

On Tue, Sep 11, 2018 at 8:10 AM Lance Bragstad <lbragstad at gmail.com> wrote:

> Extra eyes on the API would be appreciated. We're also close to the point
> where we can start incorporating oslo.limit into services, so preparing
> those changes might be useful, too.
>
> One of the outcomes from yesterday's session was that Jay and Mel (from
> nova) were going to work out some examples we could use to finish up the
> enforcement code in oslo.limit. Helping out with that or picking it up
> would certainly help move the ball forward in nova.
>
>
>
>
> On Tue, Sep 11, 2018 at 1:15 AM Jaze Lee <jazeltq at gmail.com> wrote:
>
>> I recommend lijie at 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 <lbragstad at 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 <jazeltq at gmail.com> wrote:
>> >>
>> >> Lance Bragstad <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> wrote:
>> >> >>
>> >> >> On Stein only one service?
>> >> >> Is there some methods to move this more fast?
>> >> >> Lance Bragstad <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>
>> 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://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
>> >
>> >
>> __________________________________________________________________________
>> > 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181109/453ea469/attachment-0001.html>