<div dir="ltr"><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">The domain, at this stage won't be a problem to be concerned with, we<br></span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">will have its value. The only thing to add, I think, would be some kind<br></span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">of caching for keystone_user_role call to avoid repetition. This<br></span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">shouldn't be hard to implement though.</span></blockquote><div><br></div><div>Well yes, we can create method in parent keystone.rb module and global variable,</div><div>for keeping (caching) current roles. Like it done currently for domains:</div><div><br></div><div><a href="https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone.rb#L106-L130">https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone.rb#L106-L130</a><br></div><div><br></div><div>Are our solutions same?</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">I've added this as a meeting point for tomorrow, so that we can take a<br></span><span style="color:rgb(0,0,0);font-size:12.8000001907349px">final decision on this and start coding:<br></span><span style="color:rgb(0,0,0);font-size:12.8000001907349px"> - </span><a href="https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322" rel="noreferrer" target="_blank" style="font-size:12.8000001907349px">https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322</a></blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">Yep, that have to be discussed.</div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-21 18:09 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Denis Egorenko <<a href="mailto:degorenko@mirantis.com">degorenko@mirantis.com</a>> writes:<br>
<br>
> Hi Athlan,<br>
><br>
> thanks for attention of this problem. We have one more related change<br>
> [1] and bug [2]<br>
> for this problem, when we option 'domain_specific_drivers' is used.<br>
><br>
> I would like to vote for 3) case.<br>
><br>
> As I see it there are three ways to approach this:<br>
> - iterate over all domains and keep the same behavior as now;<br>
> - detect somehow that the domain-specific configuration is used<br>
> and<br>
> hack, both instances methods to add domain options<br>
> - remove prefetch from keystone_user and keystone_user_role (kinda<br>
> get<br>
> my preference, see below)<br>
<br>
</span>We agree then :)<br>
<span class=""><br>
> Let me explain why.<br>
> Using of prefetch and instances methods have a couple of problem, like<br>
> we can't pass some values to them and can't to set proper options<br>
> (dynamical of course).<br>
> Backing to this problem, it means, that we can't specify some domain<br>
> and hence we can<br>
> iterate over all domains or check users only for default domain. Both<br>
> ways are not acceptable to me.<br>
><br>
> As solution for this problem, i see using calling kinda of instances<br>
> method from exist? method.<br>
> On this stage we can use all parameters, which are passed to<br>
> keystone_user{_role}<br>
> providers and we can choose proper domain if specified. If not -<br>
> default domain will be used.<br>
<br>
</span>The domain, at this stage won't be a problem to be concerned with, we<br>
will have its value. The only thing to add, I think, would be some kind<br>
of caching for keystone_user_role call to avoid repetition. This<br>
shouldn't be hard to implement though.<br>
<br>
I've added this as a meeting point for tomorrow, so that we can take a<br>
final decision on this and start coding:<br>
- <a href="https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322</a><br>
<div class=""><div class="h5"><br>
><br>
> [1] <a href="https://review.openstack.org/213906" rel="noreferrer" target="_blank">https://review.openstack.org/213906</a><br>
> [2] <a href="https://bugs.launchpad.net/puppet-keystone/+bug/1485508" rel="noreferrer" target="_blank">https://bugs.launchpad.net/puppet-keystone/+bug/1485508</a><br>
><br>
> 2016-03-21 16:34 GMT+03:00 Sofer Athlan-Guyot <<a href="mailto:sathlang@redhat.com">sathlang@redhat.com</a>>:<br>
><br>
> Hi,<br>
><br>
> we have a big problem when using domain-specific configuration.<br>
> The<br>
> listing of all users is not supported by keystone when it's used<br>
> [1][2].<br>
><br>
> What this means is that prefetch method in keystone_user won't<br>
> work, or<br>
> more specifically, instances method will fail.<br>
><br>
> This poses a problem for the keystone_user_role, as the user<br>
> instances<br>
> method is called there too.<br>
><br>
> The missing bit when domain-specific configuration is used is that<br>
> 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<br>
> and<br>
> hack, both instances methods to add domain options<br>
> - remove prefetch from keystone_user and keystone_user_role (kinda<br>
> get<br>
> my preference, see below)<br>
><br>
> The problem I see with the first two methods depends on the usual<br>
> use<br>
> case of the domain specific configuration.<br>
><br>
> For what I understand, this would be mainly used to connect to<br>
> existing<br>
> LDAP server, certainly large AD. If that's the case then we will<br>
> have<br>
> the same problem that the keystone people have seen, ie very big<br>
> list of<br>
> poeple, most of them unrelated to what is happening. We will then<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> bug<br>
> report[3] and started to work on a fix here[4]<br>
><br>
> [1]<br>
> <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><br>
> (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>
> --<br>
> Sofer Athlan-Guyot<br>
><br>
> __________________________________________________________________________<br>
><br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <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>
<br>
--<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>
</div></div></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></div>