Open Stack

Denis Egorenko <degorenko at mirantis.com> writes:

> Hi Athlan,
>
> thanks for attention of this problem. We have one more related change
> [1] and bug [2]
> for this problem, when we option 'domain_specific_drivers' is used.
>
> I would like to vote for 3) case.
>
>     As I see it there are three ways to approach this:
>     - iterate over all domains and keep the same behavior as now;
>     - detect somehow that the domain-specific configuration is used
>     and
>     hack, both instances methods to add domain options
>     - remove prefetch from keystone_user and keystone_user_role (kinda
>     get
>     my preference, see below)

We agree then :)

> Let me explain why.
> Using of prefetch and instances methods have a couple of problem, like
> we can't pass some values to them and can't to set proper options
> (dynamical of course).
> Backing to this problem, it means, that we can't specify some domain
> and hence we can
> iterate over all domains or check users only for default domain. Both
> ways are not acceptable to me.
>
> As solution for this problem, i see using calling kinda of instances
> method from exist? method.
> On this stage we can use all parameters, which are passed to
> keystone_user{_role}
> providers and we can choose proper domain if specified. If not -
> default domain will be used.

The domain, at this stage won't be a problem to be concerned with, we
will have its value.  The only thing to add, I think, would be some kind
of caching for keystone_user_role call to avoid repetition.  This
shouldn't be hard to implement though.

I've added this as a meeting point for tomorrow, so that we can take a
final decision on this and start coding:
 - https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322

>
> [1] https://review.openstack.org/213906
> [2] https://bugs.launchpad.net/puppet-keystone/+bug/1485508
>
> 2016-03-21 16:34 GMT+03:00 Sofer Athlan-Guyot <sathlang at redhat.com>:
>
>     Hi,
>     
>     we have a big problem when using domain-specific configuration.
>     The
>     listing of all users is not supported by keystone when it's used
>     [1][2].
>     
>     What this means is that prefetch method in keystone_user won't
>     work, or
>     more specifically, instances method will fail.
>     
>     This poses a problem for the keystone_user_role, as the user
>     instances
>     method is called there too.
>     
>     The missing bit when domain-specific configuration is used is that
>     the
>     operator must precise the domain on the command line option.
>     
>     As I see it there are three ways to approach this:
>     
>     - iterate over all domains and keep the same behavior as now;
>     - detect somehow that the domain-specific configuration is used
>     and
>     hack, both instances methods to add domain options
>     - remove prefetch from keystone_user and keystone_user_role (kinda
>     get
>     my preference, see below)
>     
>     The problem I see with the first two methods depends on the usual
>     use
>     case of the domain specific configuration.
>     
>     For what I understand, this would be mainly used to connect to
>     existing
>     LDAP server, certainly large AD. If that's the case then we will
>     have
>     the same problem that the keystone people have seen, ie very big
>     list of
>     poeple, most of them unrelated to what is happening. We will then
>     have
>     the risk that:
>     - keystone fails;
>     - the puppet process would be slowed down significantly;
>     
>     So listing all users in this case seems like a very bad idea. As I
>     don't see a way to disable prefetching dynamically, when
>     domain-specific
>     is used (maybe have to be digged into ?), then I tend to favor the
>     removal of this from kesytone_user and keystone_user_role.
>     Keystone_user_role is the main problem here as it require a lot of
>     call
>     to be build and prefetching help here.
>     
>     So I don't see a best solution to this problem, so I'd like to
>     have more
>     inputs about the right course of action.
>     
>     Note: It was first noticed by Matthew J Black, which has open this
>     bug
>     report[3] and started to work on a fix here[4]
>     
>     [1]
>     https://github.com/openstack/keystone/blob/master/doc/source/configuration.rst
>    (look for domain-specific)
>     [2] https://bugs.launchpad.net/keystone/+bug/1555629
>     [3] https://bugs.launchpad.net/puppet-keystone/+bug/1554555
>     [4] https://review.openstack.org/#/c/289995/
>     --
>     Sofer Athlan-Guyot
>     
>     __________________________________________________________________________
>    
>     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

-- 
Sofer Athlan-Guyot