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
