Open Stack

On Apr 5, 2011, at 9:07 AM, Sandy Walsh wrote:

> 
>> groups = AuthZ.get_resource_groups('alice')
>> instances = set()
>> for group in groups:
>>    instances.union(set(nova.get_instances(group)))
>> return instances
> 
> Agree that this could result in lots of little queries as written above, but the db can do all the work quite easily with some small tweaks.
> 
> return nova.get_instances(groups)

Ok so we are aggregating at the service layer.  That does make optimization a bit easier.  Especially if the user can specify with the OnBehalfOf idea a subset of the instances he wants to list.

> 
>> I would still suggest that this makes some actions inside a service very annoying.  How does one list all of the
>> instances belonging to an organization, or accessible to a user?  Do we push to the client side?
>> 
>> I'm also not sure that it gives us useful control over something like roles.  Imagine Jon, a security adminstrator
>> for OrganizationA. You want him to be able to network isolate vms for OrganizationA.   How do you specify
>> that he can isolate any one of OrganizationAs instances?
>> 
>> (Jon, can_isolate, ????)
>> Is it assumed that we specify a special role and Auth is going to return a giant list of all of the resource
>> groups that are in organizationA?
> 
> Either that or a wildcard for all perhaps?
> 
> (Jon, can_isolate, *)

Wildcards won't work if one provider is supporting multiple organizations (this has been specifically requested by some clients btw, so it isn't just astronauting), unless we support more of a regex wildcard:

(jon, can_isolate, OrganizationA.*)


That would be a cool feature, but it would require the auth service to return groups according to a specific format.  Otherwise, the giant list should definitely work up to a certain size.

Vish