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 <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
__________________________________________________________________________
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
