Open Stack

Ok,

so during the meeting yesterday, we have agree that prefetch
should go away.  I think that we have agree as well that LDAP setup for
proper testing of multiple backends is required.

I have started a very, very early non-working review there for the LDAP
part[1].  I have chosen the camptocamp ldap[2] module as it is approved
by puppetlabs.

For reference I'm using the devstack ldap code[3].  I'm not a ldap
master, so if you have any input, that would be appreciated.

In parallel, I plan to start the removal of the prefetch in
keystone_user and keystone_user_role on top of the previous review.

Is that an ok plan for everyone ?

[1] https://review.openstack.org/#/c/296370/
[2] https://forge.puppetlabs.com/camptocamp/openldap
[3] https://github.com/openstack-dev/devstack/blob/master/lib/ldap

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