URL: https://github.com/SSSD/sssd/pull/106 Title: #106: Add a new "files" provider
jhrozek commented: """ On Mon, Jan 23, 2017 at 03:20:47AM -0800, Pavel Březina wrote: > On 01/20/2017 09:01 PM, Jakub Hrozek wrote: > > On Fri, Jan 20, 2017 at 04:05:47AM -0800, Pavel Březina wrote: > >> @lslebodn Asked me to address my comments in separate patches. I wrote > > patches for most of the above expect changing the `sf_` prefix and > > removing logic that disables domain during enumeration. This is > > something I want to agree upon with @jhrozek first. > > > > Thank you very much, I will try to merge the commits in the next couple > > of days or so. > > > > btw I was thinking about the disabled domains as well. I wonder if the > > best way to go is to let the cache_req queue the requests for the > > disabled domain and then after a timeout, just return 'not found'. > > I want to avoid implementing any sort of queue inside cache_req. At this > moment we do not contact data provider for files. Would it be big > performance lost if we do it the other way around, i.e. always contact > data provider? > > The idea would be: > 1) Contact data provider. > 2) DP would no if there is any ongoing update > yes) Wait until the update is finished and return (queue is already > implemented) > no) Return immediately. > > In 2) We can check if the caller is nss and if yes we can immediately > return with a specific return code to indicate that passwd should be > asked directly. I need to measure how much time there is spent in the IPC. Maybe it would be doable as repeated requests would be answered from the memory cache anyway. > > This would be the easiest and cleanest approach in my opinion. > > If the performance lost will be significant, we can change it to call > data provider only on the update process. OK, in this case I would prefer not to use 'disabled' as the state that the provider sets but add a new state, maybe 'dirty' or 'inconsistent' and amend cache_req to send a DP update when there are requests against a domain in this state. I still think we need some short timeout (couple of seconds at max) to protect against issues in the DP update that would block any NSS request, though. If we see later that there are issues with update, we can either improve the performance of the back end update or just fall through. """ See the full comment at https://github.com/SSSD/sssd/pull/106#issuecomment-274770015
_______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
