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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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
