On Tue, Apr 05, 2011 at 01:53:46AM +0000, Sandy Walsh wrote: > From: Vishvananda Ishaya [vishvana...@gmail.com] > > 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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
