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@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
