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
