On 11/09/2015 14:32, Rich Megginson wrote:
> On 09/11/2015 04:17 AM, 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.
>
> Can you explain more about "fully hierarchical names"? What is the
> string representation?
sorry no because there was no agreement on it
david
>
>>
>> regards
>>
>> David
>>
>> 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
>
__________________________________________________________________________
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
