My Comments in line. Arvind
-----Original Message----- From: Adam Young [mailto:ayo...@redhat.com] Sent: Tuesday, December 10, 2013 2:54 PM To: David Chadwick; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions) Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev] [keystone] Service scoped role definition On 12/10/2013 04:26 PM, David Chadwick wrote: > 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. Unnecessary. You are basically putting in documentation about how they are to be enforced, which does not belong there. Just do the basic: allow for the role naming to be nested under projects and domains, and use that to support your use case. This discussion is taking up too much time and effort. Please stop trying to make it more complex than necessary. AT: We are not putting in documentation but we are trying to come up with generic role data model so that it will support all (private and public cloud) of our role needs as explained in BP and extensible. If you really have a solution for all the problems listed in below BPs, please draft it and present in detail. So far, two high level ideas (nested role-def and name space) proposed by you are not helping which is clear. https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens. I will appreciate and definitely consider them if they will resolve our problems. >> >> Thoughts? >> >> >> >> Thanks, Arvind >> >> >> >> -----Original Message----- From: David Chadwick >> [mailto:d.w.chadw...@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.math...@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 >> _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
