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 <jaze...@gmail.com
<mailto:jaze...@gmail.com>> wrote:
Lance Bragstad <lbrags...@gmail.com
<mailto:lbrags...@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 <jaze...@gmail.com
<mailto:jaze...@gmail.com>> wrote:
>>
>> On Stein only one service?
>> Is there some methods to move this more fast?
>> Lance Bragstad <lbrags...@gmail.com
<mailto:lbrags...@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 <jaze...@gmail.com
<mailto:jaze...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
