Open Stack

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

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
>