Open Stack

+1

Given the rest of the OpenStack quota handling is per project, we should be consistent (i.e. no per-user or per-group quotas, just per-project).

In the long term, unified limits will allow us to have the finer grain control (by creating sub-projects for specific use cases).

However, in my experience, this level of control for server groups should be deprecated.

If there are use cases, let’s address them with the new facilities that are being developed in an upcoming forum.

Tim

From: Jay Pipes <jaypipes at gmail.com>
Date: Wednesday, 13 March 2019 at 15:44
To: melanie witt <melwittt at gmail.com>
Cc: "openstack-discuss at lists.openstack.org" <openstack-discuss at lists.openstack.org>
Subject: Re: [nova] Does anyone remember why server_group_members quota is enforced at the user rather than project level?

On Mon, Mar 11, 2019 at 4:10 PM melanie witt <melwittt at gmail.com<mailto:melwittt at gmail.com>> wrote:
On Thu, 7 Mar 2019 09:08:46 -0600, Matt Riedemann <mriedemos at gmail.com<mailto:mriedemos at gmail.com>>
wrote:
> Change [1] in Juno added the server_groups and server_group_members quotas.
>
> Server group quota is counted per project and user [2].
>
> Server group member quota is only counted per group and user [3].
>
> The question coming up in IRC today is why is the server group member
> count not also constrained by project? Or is project implied since the
> member count is within the scope of a group, which is itself per-project?
>
> Note that the original change that added these quotas said, "They can be
> defined per project or per user within a project".

When it says, "they can be defined per project or per user within a
project," that means the quota _limit_ can be defined per project or per
user. Which means, you can define a quota of 100 server group members
for anyone in project A, but could restrict user B in project A to only
10 server group members, if you wanted to. So, the quota limit is
definable per project or per project + user.

This is different than how the server group members are counted. As you
pointed out, server group members are counted only per user, not per
project. I don't know the reasoning behind it either. It might be like
you speculated, that since server groups are owned by a project, then
server group members have a project implied.

> Given none of the people that originally added this are around still
> maintaining it, nor was there a spec (we didn't have specs in Juno),
> we're left to guess as to the reasons.
>
> If we changed the server_group_members quota enforcement to count per
> group/project/user, would that break anything?

It would behave differently, but I'm not aware of anything that would
break. When we talked about moving nova to unified limits, I think the
plan was to change any existing per-user counts to count by project
instead (along with deprecating any per-user quota limit setting). I
think that server group members and key pairs are the only two that
count by user only, today.

Yep, and IMHO, keypairs is the one and only valid user-specific limit.

A quota on server group members just never really made any sense to me to begin with. a) making it per-user doesn't make much sense and b) this is a perfect example of using quotas as a poor man's rate-limiting middleware (just like having quotas on any "resource" that is essentially just a record in a database -- i.e. any of the quotas on things like metadata items...)

We should just get rid of the server group and server group members quotas entirely, IMHO.

Best,
-jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190313/b0fb556d/attachment-0001.html>