Open Stack

On 11/09/15 20:17, David Chadwick wrote:
> Whichever approach is adopted you need to consider the future and the
> longer term objective of moving to fully hierarchical names. I believe
> the current Keystone approach is only an interim one, as it only
> supports partial hierarchies. Fully hierarchical names has been
> discussed in the Keystone group, but I believe that this has been
> shelved until later in order to get a quick fix released now.
> 
> regards
> 
> David
> 

Thanks David,

That's interesting.
So sub projects are pushing the issue further down.
And maybe one day sub domains and sub users?

keystone_role_user {
'user.subuser::domain1 at project.subproject.subsubproject::domain2':
roles => [...]
}

or

keystone_role_user {'user.subuser':
  user_domain => 'domain1',
  tenant => 'project.subproject',
  tenant_domain => 'domain2',
  roles => [...]
}

I tend to think the domain must stick with the name it's associated
with, otherwise we have to say 'here the domain for this and that, etc'.



> On 11/09/2015 08:03, Gilles Dubreuil wrote:
>> Hi,
>>
>> Today in the #openstack-puppet channel a discussion about the pro and
>> cons of using domain parameter for Keystone V3 has been left opened.
>>
>> The context
>> ------------
>> Domain names are needed in Openstack Keystone V3 for identifying users
>> or groups (of users) within different projects (tenant).
>> Users and groups are uniquely identified within a domain (or a realm as
>> opposed to project domains).
>> Then projects have their own domain so users or groups can be assigned
>> to them through roles.
>>
>> In Kilo, Keystone V3 have been introduced as an experimental feature.
>> Puppet providers such as keystone_tenant, keystone_user,
>> keystone_role_user have been adapted to support it.
>> Also new ones have appeared (keystone_domain) or are their way
>> (keystone_group, keystone_trust).
>> And to be backward compatible with V2, the default domain is used when
>> no domain is provided.
>>
>> In existing providers such as keystone_tenant, the domain can be either
>> part of the name or provided as a parameter:
>>
>> A. The 'composite namevar' approach:
>>
>>    keystone_tenant {'projectX::domainY': ... }
>>  B. The 'meaningless name' approach:
>>
>>   keystone_tenant {'myproject': name='projectX', domain=>'domainY', ...}
>>
>> Notes:
>>  - Actually using both combined should work too with the domain
>> supposedly overriding the name part of the domain.
>>  - Please look at [1] this for some background between the two approaches:
>>
>> The question
>> -------------
>> Decide between the two approaches, the one we would like to retain for
>> puppet-keystone.
>>
>> Why it matters?
>> ---------------
>> 1. Domain names are mandatory in every user, group or project. Besides
>> the backward compatibility period mentioned earlier, where no domain
>> means using the default one.
>> 2. Long term impact
>> 3. Both approaches are not completely equivalent which different
>> consequences on the future usage.
>> 4. Being consistent
>> 5. Therefore the community to decide
>>
>> The two approaches are not technically equivalent and it also depends
>> what a user might expect from a resource title.
>> See some of the examples below.
>>
>> Because OpenStack DB tables have IDs to uniquely identify objects, it
>> can have several objects of a same family with the same name.
>> This has made things difficult for Puppet resources to guarantee
>> idem-potency of having unique resources.
>> In the context of Keystone V3 domain, hopefully this is not the case for
>> the users, groups or projects but unfortunately this is still the case
>> for trusts.
>>
>> Pros/Cons
>> ----------
>> A.
>>   Pros
>>     - Easier names
>>   Cons
>>     - Titles have no meaning!
>>     - Cases where 2 or more resources could exists
>>     - More difficult to debug
>>     - Titles mismatch when listing the resources (self.instances)
>>
>> B.
>>   Pros
>>     - Unique titles guaranteed
>>     - No ambiguity between resource found and their title
>>   Cons
>>     - More complicated titles
>>
>> Examples
>> ----------
>> = Meaningless name example 1=
>> Puppet run:
>>   keystone_tenant {'myproject': name='project_A', domain=>'domain_1', ...}
>>
>> Second run:
>>   keystone_tenant {'myproject': name='project_A', domain=>'domain_2', ...}
>>
>> Result/Listing:
>>
>>   keystone_tenant { 'project_A::domain_1':
>>     ensure  => 'present',
>>     domain  => 'domain_1',
>>     enabled => 'true',
>>     id      => '7f0a2b670f48437ba1204b17b7e3e9e9',
>>   }
>>    keystone_tenant { 'project_A::domain_2':
>>     ensure  => 'present',
>>     domain  => 'domain_2',
>>     enabled => 'true',
>>     id      => '4b8255591949484781da5d86f2c47be7',
>>   }
>>
>> = Composite name example 1  =
>> Puppet run:
>>   keystone_tenant {'project_A::domain_1', ...}
>>
>> Second run:
>>   keystone_tenant {'project_A::domain_2', ...}
>>
>> # Result/Listing
>>   keystone_tenant { 'project_A::domain_1':
>>     ensure  => 'present',
>>     domain  => 'domain_1',
>>     enabled => 'true',
>>     id      => '7f0a2b670f48437ba1204b17b7e3e9e9',
>>    }
>>   keystone_tenant { 'project_A::domain_2':
>>     ensure  => 'present',
>>     domain  => 'domain_2',
>>     enabled => 'true',
>>     id      => '4b8255591949484781da5d86f2c47be7',
>>    }
>>
>> = Meaningless name example 2  =
>> Puppet run:
>>   keystone_tenant {'myproject1': name='project_A', domain=>'domain_1', ...}
>>   keystone_tenant {'myproject2': name='project_A', domain=>'domain_1',
>> description=>'blah'...}
>>
>> Result: project_A in domain_1 has a description
>>
>> = Composite name example 2  =
>> Puppet run:
>>   keystone_tenant {'project_A::domain_1', ...}
>>   keystone_tenant {'project_A::domain_1', description => 'blah', ...}
>>
>> Result: Error because the resource must be unique within a catalog
>>
>> My vote
>> --------
>> I would love to have the approach A for easier name.
>> But I've seen the challenge of maintaining the providers behind the
>> curtains and the confusion it creates with name/titles and when not sure
>> about the domain we're dealing with.
>> Also I believe that supporting self.instances consistently with
>> meaningful name is saner.
>> Therefore I vote B
>>
>> Finally
>> ------
>> Thanks for reading that far!
>> To choose, please provide feedback with more pros/cons, examples and
>> your vote.
>>
>> Thanks,
>> Gilles
>>
>>
>> PS:
>> [1] https://groups.google.com/forum/#!topic/puppet-dev/CVYwvHnPSMc
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>