Open Stack

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