Open Stack

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?
>
> 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
>
> 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
>
> 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.
>
> Chris
>
> __________________________________________________________________________
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180307/22276bec/attachment.sig>