Open Stack

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/20180911/b7a6251a/attachment.html>