We also encounter this problem when a user creates a VM in a project (with multiple project administrators) and the user then leaves CERN. This then means the user's keypair is removed. Not sure what the best solution for this is but having a project keypair list which could contain keypairs for the project administrators would be interesting possibility. However, adding new administrators (and updating the keypair list) is not obvious. (I'd also be in favour of no per-user quotas, BTW) Tim -----Original Message----- From: Lance Bragstad <lbragstad@gmail.com> Date: Thursday, 14 March 2019 at 16:16 To: <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 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. >