openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

On Tue, Apr 05, 2011 at 01:53:46AM +0000, Sandy Walsh wrote:
> From: Vishvananda Ishaya [vishvananda@xxxxxxxxx]
> > Eric:
> > I agree that your suggestion is simpler, but I think we are too limited if we remove multi-membership and per-
> > object overrides.  Imagine that alice is an organization that has 10 users and a lot of instances.  If i create a group
> > called alice_shares, then I have to remember to add all of other 10 users of alice to that group, and the instances
> > are no longer logically grouped because they will show up at a different url or require a different set of 
> > credentials to access.  This sucks from a usability perspective.  I should also mention that if we are going
> > to the trouble of making an api to create new groups anyway, it might be better to just bite the bullet
> >  and jump into multiple ownership.
> 
> Agree, as per my previous email. I think the effort to support multiple user accounts is no different than managing multiple resource groups. 

The extra cost is this introduces a new type. If we are going with an
authenticated user returning a list of accounts or account/action
tuples, then having another type for resource groups seems
excessive. It seems we only need one mapping layer here, not two.

I'm not sure if we're agreeing with different terminology or if
there are actually differences. :)  What I interpreted on the wiki
didn't seem to line up with how we were talking last Friday on IRC,
but this could be my misunderstanding.

-Eric