Open Stack

Adam Young <ayoung at redhat.com> writes:

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

I think it was more a performance related problem.  For user_role you
have to make a lot of calls to get all the associations.  The natural
way in puppet to have those calls only once is to use prefetch.

>
> Would better support from Keystone server make a difference here?

At this point I don't see which query would be useful, here.  The
user_role construction is involving, but I can't see how a keystone
evolution would ease it.  Maybe someone has a better answer for this.

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