[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