<div dir="ltr">Hi Athlan,<div><br></div><div>thanks for attention of this problem. We have one more related change [1] and bug [2]</div><div>for this problem, when we option '<span style="color:rgb(0,0,0);font-family:monospace;white-space:pre">domain_specific_drivers'</span> is used<span style="color:rgb(0,0,0);font-family:monospace;white-space:pre">.</span></div><div><span style="color:rgb(0,0,0);font-family:monospace;white-space:pre"><br></span></div><div>I would like to vote for 3) case.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="color:rgb(0,0,0);font-size:12.8000001907349px">As I see it there are three ways to approach this:</span><br style="color:rgb(0,0,0);font-size:12.8000001907349px"><span style="color:rgb(0,0,0);font-size:12.8000001907349px"> - iterate over all domains and keep the same behavior as now;<br></span><span style="color:rgb(0,0,0);font-size:12.8000001907349px"> - detect somehow that the domain-specific configuration is used and<br></span><span style="color:rgb(0,0,0);font-size:12.8000001907349px"> hack, both instances methods to add domain options<br></span><span style="color:rgb(0,0,0);font-size:12.8000001907349px"> - remove prefetch from keystone_user and keystone_user_role (kinda get<br></span><span style="color:rgb(0,0,0);font-size:12.8000001907349px"> my preference, see below)</span></blockquote><div><br></div><div>Let me explain why.<br></div><div>Using of prefetch and instances methods have a couple of problem, like</div><div>we can't pass some values to them and can't to set proper options (dynamical of course).</div><div>Backing to this problem, it means, that we can't specify some domain and hence we can<br></div><div>iterate over all domains or check users only for default domain. Both ways are not acceptable to me.</div><div><br></div><div>As solution for this problem, i see using calling kinda of instances method from exist? method.</div><div>On this stage we can use all parameters, which are passed to keystone_user{_role}</div><div>providers and we can choose proper domain if specified. If not - default domain will be used.</div><div><br></div><div>[1] <a href="https://review.openstack.org/213906">https://review.openstack.org/213906</a></div><div>[2] <a href="https://bugs.launchpad.net/puppet-keystone/+bug/1485508">https://bugs.launchpad.net/puppet-keystone/+bug/1485508</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-21 16:34 GMT+03:00 Sofer Athlan-Guyot <span dir="ltr"><<a href="mailto:sathlang@redhat.com" target="_blank">sathlang@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
we have a big problem when using domain-specific configuration. The<br>
listing of all users is not supported by keystone when it's used[1][2].<br>
<br>
What this means is that prefetch method in keystone_user won't work, or<br>
more specifically, instances method will fail.<br>
<br>
This poses a problem for the keystone_user_role, as the user instances<br>
method is called there too.<br>
<br>
The missing bit when domain-specific configuration is used is that the<br>
operator must precise the domain on the command line option.<br>
<br>
As I see it there are three ways to approach this:<br>
<br>
- iterate over all domains and keep the same behavior as now;<br>
- detect somehow that the domain-specific configuration is used and<br>
hack, both instances methods to add domain options<br>
- remove prefetch from keystone_user and keystone_user_role (kinda get<br>
my preference, see below)<br>
<br>
The problem I see with the first two methods depends on the usual use<br>
case of the domain specific configuration.<br>
<br>
For what I understand, this would be mainly used to connect to existing<br>
LDAP server, certainly large AD. If that's the case then we will have<br>
the same problem that the keystone people have seen, ie very big list of<br>
poeple, most of them unrelated to what is happening. We will then have<br>
the risk that:<br>
- keystone fails;<br>
- the puppet process would be slowed down significantly;<br>
<br>
So listing all users in this case seems like a very bad idea. As I<br>
don't see a way to disable prefetching dynamically, when domain-specific<br>
is used (maybe have to be digged into ?), then I tend to favor the<br>
removal of this from kesytone_user and keystone_user_role.<br>
Keystone_user_role is the main problem here as it require a lot of call<br>
to be build and prefetching help here.<br>
<br>
So I don't see a best solution to this problem, so I'd like to have more<br>
inputs about the right course of action.<br>
<br>
Note: It was first noticed by Matthew J Black, which has open this bug<br>
report[3] and started to work on a fix here[4]<br>
<br>
[1] <a href="https://github.com/openstack/keystone/blob/master/doc/source/configuration.rst" rel="noreferrer" target="_blank">https://github.com/openstack/keystone/blob/master/doc/source/configuration.rst</a> (look for domain-specific)<br>
[2] <a href="https://bugs.launchpad.net/keystone/+bug/1555629" rel="noreferrer" target="_blank">https://bugs.launchpad.net/keystone/+bug/1555629</a><br>
[3] <a href="https://bugs.launchpad.net/puppet-keystone/+bug/1554555" rel="noreferrer" target="_blank">https://bugs.launchpad.net/puppet-keystone/+bug/1554555</a><br>
[4] <a href="https://review.openstack.org/#/c/289995/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/289995/</a><br>
<span class="HOEnZb"><font color="#888888">--<br>
Sofer Athlan-Guyot<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div style="color:rgb(136,136,136)"><span style="font-family:arial;font-size:small">Best Regards,</span><br></div><span style="color:rgb(136,136,136)">Egorenko Denis</span>,</div><div><font color="#888888">Senior</font><span style="color:rgb(136,136,136)"> Deployment Engineer</span><br style="color:rgb(136,136,136)"><span style="color:rgb(136,136,136)">Mirantis</span><br></div></div></div></div></div>
</div>