[nova] Does anyone remember why server_group_members quota is enforced at the user rather than project level?

Zane Bitter zbitter at redhat.com
Thu Mar 14 14:18:58 UTC 2019


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.



More information about the openstack-discuss mailing list