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