Denis Egorenko <degore...@mirantis.com> writes: > Hi Athlan, > > thanks for attention of this problem. We have one more related change > [1] and bug [2] > for this problem, when we option 'domain_specific_drivers' is used. > > I would like to vote for 3) case. > > 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)
We agree then :) > Let me explain why. > Using of prefetch and instances methods have a couple of problem, like > we can't pass some values to them and can't to set proper options > (dynamical of course). > Backing to this problem, it means, that we can't specify some domain > and hence we can > iterate over all domains or check users only for default domain. Both > ways are not acceptable to me. > > As solution for this problem, i see using calling kinda of instances > method from exist? method. > On this stage we can use all parameters, which are passed to > keystone_user{_role} > providers and we can choose proper domain if specified. If not - > default domain will be used. The domain, at this stage won't be a problem to be concerned with, we will have its value. The only thing to add, I think, would be some kind of caching for keystone_user_role call to avoid repetition. This shouldn't be hard to implement though. I've added this as a meeting point for tomorrow, so that we can take a final decision on this and start coding: - https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322 > > [1] https://review.openstack.org/213906 > [2] https://bugs.launchpad.net/puppet-keystone/+bug/1485508 > > 2016-03-21 16:34 GMT+03:00 Sofer Athlan-Guyot <sathl...@redhat.com>: > > 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) > > 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/ > -- > Sofer Athlan-Guyot > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sofer Athlan-Guyot __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev