On 03/07/2018 09:49 AM, Lance Bragstad wrote:


On 03/07/2018 09:31 AM, Chris Friesen wrote:
On 03/07/2018 08:58 AM, Lance Bragstad wrote:
Hi all,

Per the identity-integration track at the PTG [0], I proposed a new oslo
library for services to use for hierarchical quota enforcement [1]. Let
me know if you have any questions or concerns about the library. If the
oslo team would like, I can add an agenda item for next weeks oslo
meeting to discuss.

Thanks,

Lance

[0] https://etherpad.openstack.org/p/unified-limits-rocky-ptg

Looks interesting.

Some complications related to quotas:

1) Nova currently supports quotas for a user/group tuple that can be
stricter than the overall quotas for that group.  As far as I know no
other project supports this.
By group, do you mean keystone group? Or are you talking about the quota
associated to a project?

Sorry, typo. I meant quotas for a user/project tuple, which can be stricter than the overall quotas for that project.

2) Nova and cinder also support the ability to set the "default" quota
class (which applies to any group that hasn't overridden their
quota).  Currently once it's set there is no way to revert back to the
original defaults.
This sounds like a registered limit [0], but again, I'm not exactly sure
what "group" means in this context. It sounds like group is supposed to
be a limit for a specific project?

[0]
https://docs.openstack.org/keystone/latest/admin/identity-unified-limits.html#registered-limits

Again, should be project instead of group. And registered limits seem essentially analogous.


3) Neutron allows you to list quotas for projects with non-default
quota values.  This is useful, and I'd like to see it extended to
optionally just display the non-default quota values rather than all
quota values for that project.  If we were to support user/group
quotas this would be the only way to efficiently query which
user/group tuples have non-default quotas.
This might be something we can work into the keystone implementation
since it's still marked as experimental [1]. We have two APIs, one
returns the default limits, also known as a registered limit, for a
resource and one that returns the project-specific overrides. It sounds
like you're interested in the second one?

[1]
https://developer.openstack.org/api-ref/identity/v3/index.html#unified-limits

Again, should be user/project tuples. Yes, in this case I'm talking about the project-specific ones. (It's actually worse if you support user/project limits since with the current nova API you can potentially get combinatorial explosion if many users are part of many projects.)

I think it would be useful to be able to constrain this query to report limits for a specific project, (and a specific user if that will be supported.)

I also think it would be useful to be able to constrain it to report only the limits that have been explicitly set (rather than inheriting the default from the project or the registered limit). Maybe it's already intended to work this way--if so that should be explicitly documented.

4) In nova, keypairs belong to the user rather than the project.
(This is a bit messed up, but is the current behaviour.)  The quota
for these should really be outside of any group, or else we should
modify nova to make them belong to the project.
I think the initial implementation of a unified limit pattern is
targeting limits and quotas for things associated to projects. In the
future, we can probably expand on the limit information in keystone to
include user-specific limits, which would be great if nova wants to move
away from handling that kind of stuff.

The quota handling for keypairs is a bit messed up in nova right now, but it's legacy behaviour at this point. It'd be nice to be able to get it right if we're switching to new quota management mechanisms.

Chris


__________________________________________________________________________
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

Reply via email to