Open Stack

Hi Arvind

On 04/12/2013 19:04, Tiwari, Arvind wrote:
> Hi David,
> 
> The biggest problems in my opinion are,
> 
> 1. We are overloading and adding extra complexities on role name to
> maintain the generalization for role-def data model. 

On the contrary, having the same role name with multiple definitions (as
in your proposal) is overloading role name.

2. Name spacing
> the role name is not going to resolve all the issues listed in BP. 

It is not designed to. Each issue has its own resolution.
Hierarchical naming resolves the issue of unique role names, that's all.
It allows different entities to create the same role (sub)name that are
actually different roles and have different global names.

>3.All the namespaces are derived from mutable string  (domain name,
> project name, service name etc...) which makes the role name
> fragile.

So why are role IDs immutable and role names mutable? (ditto
project/domain/service IDs and names. What is the rationale for that?
Maybe you should not allow the names to change once they have been created.

> 
> I think it is time to break generic role-def data model to
> accommodate more specialized use cases.

That is counter-intuitive. You dont break a model to accommodate more
specialized cases. You enhance the model to take the new functionality
into account, and preferably in a backwards compatible way.

regards

David

> 
> 
> Thanks, Arvind
> 
> -----Original Message----- From: David Chadwick
> [mailto:d.w.chadwick at kent.ac.uk] Sent: Wednesday, December 04, 2013
> 10:41 AM To: Adam Young; Tiwari, Arvind; OpenStack Development
> Mailing List (not for usage questions) Cc: Henry Nash;
> dolph.mathews at gmail.com Subject: Re: [openstack-dev] [keystone]
> Service scoped role definition
> 
> Hi Adam
> 
> I understand your problem: having projects and services which have
> the same name, then the lineage of a role containing this name is
> not deterministically known without some other rule or syntax that
> can differentiate between the two.
> 
> Since domains contain projects which contain services then isnt the 
> containment hierarchy already known and predetermined? If it is
> then:
> 
> 4 name components mean it is a service specified role 3 name
> components mean it is a project specified role 2 name components mean
> it is a domain specified role 1 name component means it is globally
> named role (from the default domain)
> 
> a null string means the default domain or all projects in a domain.
> You would never have null for a service name.
> 
> admin means the global admin role /admin ditto x/admin means the
> admin of the X domain x/y/admin means the admin role for the y
> project in domain x //x/admin means admin for service x from the
> default domain etc.
> 
> will that work?
> 
> regards
> 
> David
> 
> 
> On 04/12/2013 15:04, Adam Young wrote:
>> On 12/04/2013 04:08 AM, David Chadwick wrote:
>>> I am happy with this as far as it goes. I would like to see it
>>> being made more general, where domains, services and projects can
>>> also own and name roles
>> Domains should be OK, but services would confuse the matter.  You'd
>> have to end up with something like LDAP
>> 
>> role=  domain=default,service=glance
>> 
>> vs
>> 
>> role=  domain=default,project=glance
>> 
>> unless we have unambiguous implicit ordering, we'll need to make
>> it explicit, which is messy.
>> 
>> I'd rather do:
>> 
>> One segment: globally defined roles.  These could also be
>> considered roles defined in the default domain. Two segments
>> service defined roles in the default domain Three Segments, service
>> defined roles from non-default domain
>> 
>> To do domain scoped roles we could do something like:
>> 
>> domX//admin
>> 
>> 
>> But It seems confusing.
>> 
>> Perhaps a better approach for project roles is to have the rule
>> that the default domain can show up as an empty string.  Thus,
>> project scoped roles from the default domain  would be:
>> 
>> \glance\admin
>> 
>> and from a non default domain
>> 
>> domX\glance\admin
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> 
>>> regards
>>> 
>>> David
>>> 
>>> 
>>> On 04/12/2013 01:51, Adam Young wrote:
>>>> I've been thinking about your comment that "nested roles are
>>>> confusing"
>>>> 
>>>> 
>>>> What if we backed off and said the following:
>>>> 
>>>> 
>>>> "Some role-definitions are owned by services.  If a Role
>>>> definition is owned by a service, in role assignment lists in
>>>> tokens, those roles we be prefixd by the service name.  / is a
>>>> reserved cahracter and weill be used as the divider between
>>>> segments of the role definition "
>>>> 
>>>> That drops arbitrary nesting, and provides a reasonable
>>>> namespace.  Then a role def would look like:
>>>> 
>>>> "glance/admin"  for the admin role on the glance project.
>>>> 
>>>> 
>>>> 
>>>> In theory, we could add the domain to the namespace, but that
>>>> seems unwieldy.  If we did, a role def would then look like
>>>> this
>>>> 
>>>> 
>>>> "default/glance/admin"  for the admin role on the glance
>>>> project.
>>>> 
>>>> Is that clearer than the nested roles?
>>>> 
>>>> 
>>>> 
>>>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
>>>>> Hi Adam,
>>>>> 
>>>>> Based on our discussion over IRC, I have updated the below
>>>>> etherpad with proposal for nested role definition
>>>>> 
>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition
>>>>>
>>>>>
>>>>> 
Please take a look @ "Proposal (Ayoung) - Nested role definitions", I
>>>>> am sorry if I could not catch your idea.
>>>>> 
>>>>> Feel free to update the etherpad.
>>>>> 
>>>>> Regards, Arvind
>>>>> 
>>>>> 
>>>>> -----Original Message----- From: Tiwari, Arvind Sent:
>>>>> Tuesday, November 26, 2013 4:08 PM To: David Chadwick;
>>>>> OpenStack Development Mailing List Subject: Re:
>>>>> [openstack-dev] [keystone] Service scoped role definition
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>> Thanks for your time and valuable comments. I have replied to
>>>>> your comments and try to explain why I am advocating to this
>>>>> BP.
>>>>> 
>>>>> Let me know your thoughts, please feel free to update below
>>>>> etherpad 
>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition
>>>>>
>>>>>
>>>>> 
Thanks again,
>>>>> Arvind
>>>>> 
>>>>> -----Original Message----- From: David Chadwick
>>>>> [mailto:d.w.chadwick at kent.ac.uk] Sent: Monday, November 25,
>>>>> 2013 12:12 PM To: Tiwari, Arvind; OpenStack Development
>>>>> Mailing List Cc: Henry Nash; ayoung at redhat.com;
>>>>> dolph.mathews at gmail.com; Yee, Guang Subject: Re:
>>>>> [openstack-dev] [keystone] Service scoped role definition
>>>>> 
>>>>> Hi Arvind
>>>>> 
>>>>> I have just added some comments to your blueprint page
>>>>> 
>>>>> regards
>>>>> 
>>>>> David
>>>>> 
>>>>> 
>>>>> On 19/11/2013 00:01, Tiwari, Arvind wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Based on our discussion in design summit , I have redone
>>>>>> the service_id binding with roles BP 
>>>>>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 
I have added a new BP (link below) along with detailed use case to
>>>>>> support this BP.
>>>>>> 
>>>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 
Below etherpad link has some proposals for Role REST representation
>>>>>> and pros and cons analysis
>>>>>> 
>>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition
>>>>>>
>>>>>>
>>>>>> 
Please take look and let me know your thoughts.
>>>>>> 
>>>>>> It would be awesome if we can discuss it in tomorrow's
>>>>>> meeting.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Arvind
>>>>>> 
>>>>> _______________________________________________ OpenStack-dev
>>>>> mailing list OpenStack-dev at lists.openstack.org 
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>