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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
