Open Stack

On 12/09/15 00:52, Morgan Fainberg wrote:
> On Fri, Sep 11, 2015 at 4:25 AM, Gilles Dubreuil <gilles at redhat.com
> <mailto: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', ...}
>     >>

Just for the sake of the discussion, I should have mentioned the
'classic' approach using a meaningful title (where name = title) which
doesn't work for the domain scope:

A first project comes with:
keystone_tenant {'projectX', domain=>'domainY', ...}

Another tenant with same name in a different domain cannot be created:

keystone_tenant {'projectX', domain=>'domainZ', ...}

>     >> 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.

I'm going back about this because I think it's important.

When developing Openstack providers, we grew the habit of thinking with
having multiple objects of the same family (multiple rows in a table,
the ID being the primary key).

Because of such experience, the reflex is to think of conflicts with
resources (discovery and self.instances). This has been addressed by
using the first resource found (after ordering for consistency). This is
not ideal but works for bootstrapping, more advance use to be done
directly with openstack clients.

Meanwhile there is no such need for users, groups and projects because
they are unique within a given domain. This could be a good reason to
safely use 'meaningless names'.

Besides the trusts which have to be treated separately. A trust can be
created many times with the same values, again, the ID being the only
thing to distinct them.



>     >>
>     >> 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
>     >>

In the light of the evolution of the discussion, I now vote A!

>     >> 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 believe the '::' was added because the less likely of syntax conflict.

But if there is any risk on the future then that would force us to stay
away from 'Composite names'.

> I am always a fan of explicit variables personally. It is "more complex"
> but it is also explicit. This just eliminates ambiguity.
> 

+1

I think, this is why some Keystone developers have recommended to
explicitly use the domain name.

We have to keep in mind that we are still in a transition period between
V2 and V3. For backward compatibility reasons the domain is not
mandatory which implicitly means to use the default domain. Meanwhile as
discussed in a recent weekly meeting, the domain is to be made mandatory.

This is actually fine with either A or B approach, in both cases the
domain will be made mandatory.


> --Morgan
> 
> 
> 
> __________________________________________________________________________
> 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
>