> > 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.
Well yes, we can create method in parent keystone.rb module and global variable, for keeping (caching) current roles. Like it done currently for domains: https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone.rb#L106-L130 Are our solutions same? 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 Yep, that have to be discussed. 2016-03-21 18:09 GMT+03:00 Sofer Athlan-Guyot <sathl...@redhat.com>: > 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 > -- Best Regards, Egorenko Denis, Senior Deployment Engineer Mirantis
__________________________________________________________________________ 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