Open Stack

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)


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.

[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 <sathlang at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Egorenko Denis,
Senior Deployment Engineer
Mirantis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160321/225c58a0/attachment.html>