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 <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sofer Athlan-Guyot __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
