Open Stack

>
> 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 <sathlang at redhat.com>:

> Denis Egorenko <degorenko at 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 <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
>
> --
> 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/79e727a6/attachment.html>