Open Stack

Yes, it is required to address one of public cloud use case where we want regional service admins and to support https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP. 

Based on our discussion I am going to start API specs and submit for review.

{
     "role": {
      "id": "76e72a",
      "domain_id" = "--id--",    (optional, if present, role is named by specific domain)
      "project_id" = "--id--",    (optional, if present, role is named by project)
      "service_id" = "--id--",    (optional, if present, role is named by service)
      "endpoint_id" = "--id--",    (optional, if present, role is named by service)
      "name": "---role_name---",  (must be unique when combined with domain, project and service ids)
      "scope": {"id": "---id---", (resource_id)
         "type": "service | file | domain etc.",
         "endpoint":"---endpoint---"
       }
    }
 }


For Adam's Concern, "You are over designing.  Services and Endpoints have no business in this design.  That is enforcement, not definition or assignment of the Roles.  We need a clean namespace, and mixing services and endpoints in there adds no benefit."
AT: To support following two BPs and these are the basic requirements for public cloud deployment with Keystone otherwise we are locked.  I  am asking for endpoint_id extension in role data model to support endpoint scoped tokens which you mentioned in IRC around a week back. 

1. https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
2. https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens.


Thanks.
Arvind 

-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] 
Sent: Tuesday, December 10, 2013 2:27 PM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for usage questions)
Cc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

Hi Arvind

the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.

regards

David

On 10/12/2013 16:42, Tiwari, Arvind wrote:
> Hi David,
> 
> I am cool with the proposal, just wanted to grad you attention on may
> question which I asked in my last email (which is below)
> 
> Q. what if two (or more) endpoints want to have same role_name for a
> service (nova.east.admin, nova.west.admin, nova.north.admin .....)?
> 
> (Can we think of adding an optional endpoint_id attribute in role
> data model to allow such role, which is also needed to envision
> endpoint scoped tokens for our use case)
> 
> { "role": { "id": "76e72a", "domain_id" = "--id--",    (optional, if
> present, role is named by specific domain) "project_id" = "--id--",
> (optional, if present, role is named by project) "service_id" =
> "--id--",    (optional, if present, role is named by service) 
> "endpoint_id" = "--id--",    (optional, if present, role is named by
> service) "name": "---role_name---",  (must be unique when combined
> with domain, project and service ids) "scope": {"id": "---id---",
> (resource_id) "type": "service | file | domain etc.", 
> "endpoint":"---endpoint---" } } }
> 
> For Adam's question " We are not linking role names to service id."
> (email attached) AT: These attributes are all optional and will not
> stop anyone how don't want to included service_id or (any other
> attribute) for role name uniqueness. So in particular deployment want
> to keep just the role name unique, this model will not restrict you.
> 
> Thoughts?
> 
> 
> 
> Thanks, Arvind
> 
> 
> 
> -----Original Message----- From: David Chadwick
> [mailto:d.w.chadwick at kent.ac.uk] Sent: Tuesday, December 10, 2013
> 1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing
> List (not for usage questions) Cc: Henry Nash;
> dolph.mathews at gmail.com; Yee, Guang Subject: Re: [openstack-dev]
> [keystone] Service scoped role definition
> 
> How about the following which clearly separates naming and scoping 
> constraints
> 
> { "role": { "id": "76e72a", "domain_id" = "--id--",    (optional, if
> present, role is named by specific domain) "project_id" = "--id--",
> (optional, if present, role is named by project) "service_id" =
> "--id--",    (optional, if present, role is named by service) "name":
> "---role_name---",  (must be unique when combined with domain,
> project and service ids) "scope": {"id": "---id---", (resource_id) 
> "type": "service | file | domain etc.", "endpoint":"---endpoint---" 
> } } }
> 
> regards
> 
> David
>