Open Stack

How is this different in effect than letting swift or nova be tenants? 
Each tenant gets to define users, roles, and groups, right?

On 07/13/2011 10:39 AM, Jay Pipes wrote:
> On Wed, Jul 13, 2011 at 12:45 AM, Ziad Sawalha
> <ziad.sawalha at rackspace.com>  wrote:
>> Here's a possible use case we can implement to address this:
>>
>> A service 'registers' itself with Keystone and reserves a name (Ex. Swift,
>> or nova). Keystone will guarantee uniqueness.
>> Registered services can then create roles for the service (Ex. swift:admin
>> or nova:netadmin) or tuples as suggested below (nova:delete:volume)
>> On token validation, Keystone returns these roles and a service can apply
>> it's own policies based on them.
>>
>> This is super-simplified and we can expand on it.
>> Other benefits:
>>
>> Registration would also be handy to allow services to add and manage
>> endpoints as well.
>> We can also tie this with the concept of a ClientID so services can identify
>> themselves as well with a long-lived token
>> (see https://github.com/rackspace/keystone/issues/84)
>> Common names for services could be implemented as shareable among different
>> implementations (Ex: compute:admin)
>>
>> Thoughts?
>
> Sounds like a very reasonable approach to me.
>
>> And comments inline ZNS>>
>
> Hehe, you guys need a better mail client ;)
>
> -jay
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

This email may include confidential information. If you received it in error, please delete it.