[nova] Does anyone remember why server_group_members quota is enforced at the user rather than project level?
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". 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? [1] https://review.openstack.org/#/c/104957/ [2] https://github.com/openstack/nova/blob/caa37cf099933c5aed02dcdb256055e18479f... [3] https://github.com/openstack/nova/blob/caa37cf099933c5aed02dcdb256055e18479f... -- Thanks, Matt
On Thu, 7 Mar 2019 09:08:46 -0600, Matt Riedemann <mriedemos@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. -melanie
[1] https://review.openstack.org/#/c/104957/ [2] https://github.com/openstack/nova/blob/caa37cf099933c5aed02dcdb256055e18479f... [3] https://github.com/openstack/nova/blob/caa37cf099933c5aed02dcdb256055e18479f...
On Mon, Mar 11, 2019 at 4:10 PM melanie witt <melwittt@gmail.com> wrote:
On Thu, 7 Mar 2019 09:08:46 -0600, Matt Riedemann <mriedemos@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
+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@gmail.com> Date: Wednesday, 13 March 2019 at 15:44 To: melanie witt <melwittt@gmail.com> Cc: "openstack-discuss@lists.openstack.org" <openstack-discuss@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@gmail.com<mailto:melwittt@gmail.com>> wrote: On Thu, 7 Mar 2019 09:08:46 -0600, Matt Riedemann <mriedemos@gmail.com<mailto:mriedemos@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
On 3/13/2019 8:41 AM, Jay Pipes wrote:
Yep, and IMHO, keypairs is the one and only valid user-specific limit.
Even that is a bit sketchy, since instances are owned by projects. Currently if a user starts up an instance and then leaves without sharing the keypair, other users in the same project would potentially need to rebuild the instance to update the keypair before they can log in to it. I think an argument could be made that keypairs should be owned by projects, and users should get allocated single-user projects for instances they want to keep private. Chris
On 13/03/19 5:28 PM, Chris Friesen wrote:
On 3/13/2019 8:41 AM, Jay Pipes wrote:
Yep, and IMHO, keypairs is the one and only valid user-specific limit.
Even that is a bit sketchy, since instances are owned by projects.
Came here to say this :) I assume the reason is that it allows a user to upload their public key once and use it in every project they are a member of. That's nice, but IMHO not worth the pain of having one thing in OpenStack that is scoped completely differently to everything else.
Currently if a user starts up an instance and then leaves without sharing the keypair, other users in the same project would potentially need to rebuild the instance to update the keypair before they can log in to it.
It's an even bigger problem for Heat because we have an OS::Nova::Keypair resource but everything breaks if a different user updates the stack, because the keypair that Heat created suddenly becomes invisible.
I think an argument could be made that keypairs should be owned by projects, and users should get allocated single-user projects for instances they want to keep private.
Even that is irrelevant as far as keypairs are concerned. Let's not kid ourselves that there's any "pair" involved in a keypair. You can create one without providing the private key, and if you do have Nova generate a private key, it doesn't store it. So a 'keypair' is actually just a public key. If a user has an instance they don't want other people to log into, they should not share their private key with anyone, end of story. (Obviously if you don't want other users to be able to update/delete the server through the Nova API then it should be in a project that no other users have permissions for. But this is true independently of the scope of keypairs.) cheers, Zane.
On 3/14/19 9:18 AM, Zane Bitter wrote:
On 13/03/19 5:28 PM, Chris Friesen wrote:
On 3/13/2019 8:41 AM, Jay Pipes wrote:
Yep, and IMHO, keypairs is the one and only valid user-specific limit.
Even that is a bit sketchy, since instances are owned by projects.
Came here to say this :)
I assume the reason is that it allows a user to upload their public key once and use it in every project they are a member of. That's nice, but IMHO not worth the pain of having one thing in OpenStack that is scoped completely differently to everything else.
Currently if a user starts up an instance and then leaves without sharing the keypair, other users in the same project would potentially need to rebuild the instance to update the keypair before they can log in to it.
It's an even bigger problem for Heat because we have an OS::Nova::Keypair resource but everything breaks if a different user updates the stack, because the keypair that Heat created suddenly becomes invisible.
I think an argument could be made that keypairs should be owned by projects, and users should get allocated single-user projects for instances they want to keep private.
Even that is irrelevant as far as keypairs are concerned. Let's not kid ourselves that there's any "pair" involved in a keypair. You can create one without providing the private key, and if you do have Nova generate a private key, it doesn't store it. So a 'keypair' is actually just a public key. If a user has an instance they don't want other people to log into, they should not share their private key with anyone, end of story.
I agree that you shouldn't need another project if password authentication is disabled on the server and keep private keys private. I can think of a use case that I find useful and have needed in the past that would be easier with public keys being project-scoped. As a team of developers, we had access to a project and we mostly used it for development instances. Often times we would want to debug things together on the same server, or peer program (remotely using ssh/mosh + tmux + $EDITOR). To do this, I'd add all the public keys for my team to the project, but I was the only one who could view them. If someone else joined the team, I'd need to get their public key and import it (along with anyone else on the team). My team members likely had their public keys associated to the project already for their own development instances. If things like public keys were project-scoped, I could specify a list of public keys associated to the project when I create the server. Then, I only need to manage my public keys but I get access to public keys associated to the project without having to bloat my own key pair quota. Sorry for a tangent on public keys when this thread is specific to server_group_members, but comments about key pairs tripped that use case for me.
(Obviously if you don't want other users to be able to update/delete the server through the Nova API then it should be in a project that no other users have permissions for. But this is true independently of the scope of keypairs.)
cheers, Zane.
participants (7)
-
Chris Friesen
-
Jay Pipes
-
Lance Bragstad
-
Matt Riedemann
-
melanie witt
-
Tim Bell
-
Zane Bitter