Open Stack

On Fri, Sep 11, 2015 at 4:25 AM, Gilles Dubreuil <gilles at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150911/c105d5fa/attachment.html>