On Fri, Sep 11, 2015 at 4:25 AM, Gilles Dubreuil <gil...@redhat.com> wrote:
> > > 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 > Please keep in mind that there are no "reserved" characters in projects and/or domains. It is possible to have "::" in both or ":" (or any other random entries), which couple make the composite namevar less desirable in some cases. I expect this to be a somewhat edge case (as using :: in a domain and/or project in places where it would impact the split would be somewhat odd); it can likely also be stated that using puppet requires avoiding the '::' or ':' in this manner. I am always a fan of explicit variables personally. It is "more complex" but it is also explicit. This just eliminates ambiguity. --Morgan
__________________________________________________________________________ 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