Open Stack

On 03/21/2016 09:34 AM, Sofer Athlan-Guyot wrote:
> 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)

So, listing all users ism, in general a bad idea.  I assume the reason 
is to find a userid from a user name?

Would better support from Keystone server make a difference here?

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