On Thu, Oct 26, 2017 at 02:43:29PM -0400, Simo Sorce wrote:
> On Thu, 2017-10-26 at 12:16 +0200, Jakub Hrozek wrote:
> > On Wed, Oct 25, 2017 at 05:39:21PM +0200, Sumit Bose wrote:
> > > Hi,
> > >
> > > please find below the design document for the enhanced NSS API
> > > which
> > > makes e.g. the client side timeouts which where recently refactored
> > > available to callers.
> > >
> > > A more visual friendly version can be found at:
> > > https://pagure.io/fork/sbose/SSSD/docs/blob/07514ce52845d47fe6bb327
> > > f782a865bfa75628a/f/design_pages/enhanced_nss_api.rst
> > >
> > > bye,
> > > Sumit
> >
> > LGTM!
> >
>
> Looking at this I have some questions, if you are going to create a new
> library and just need to set a timeout it seem it would be a much
> better interface to use a context handle you allocate and pass into
> each call, and then have getters setters to set timeouts or any other
> flags that should influence the whole behavior. This will allow you
> also to control how many concurrent connections you want to have
> against sssd, as each new context will create a new socket connection
> and all.
>
> In the original libnss_sss.so we could not do that because the glibc
> interface does not offer any way to hold a context, but there is no
> reason to continue along that line in a *new* API. And not using
> contexts in threaded applications is generally a bad idea, as you end
> up *requiring* te use of mutexes when that is really not always a need
> (separated threads can open separate connections and not share any data
> that require mutexes).
This sounds like a good 2.0 feature, are you interested in creating a
more detailed design page for this? Currently my goal was to reuse as
much or the current trusted code we already have.
>
> On the responder side I also do not see why new calls are being
> created. You clearly want a client-wide behavior, introduce ONE new
> call that sets flags for the rest of the connection, and just reuse the
> usual commands otherwise.
The current flags, like invalidating a cached entry are per-request,
only the single object address by the current request should be
invalidate not all object which are requested on the same connection.
>
> I do not understand what is the point of nss_truste_users why a force
> reload is a privileged operation ?
Since it can force expensive operations on the backends which will hit
servers I think not everybody should be allowed to do this.
>
> I guess DNLSGTM ?
A test-builds with a simplified version of the related patches solved
bottleneck issues with 389ds IPA modules. So at least it would help
without introducing other issues.
bye,
Sumit
>
> Simo.
>
> --
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
> ___
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
