On Mon, Mar 09, 2015 at 01:41:15PM +0100, Pavel Březina wrote:
> On 03/09/2015 01:30 PM, Jakub Hrozek wrote:
>> On Mon, Mar 09, 2015 at 01:25:22PM +0100, Pavel Březina wrote:
>>> On 03/09/2015 12:50 PM, Jakub Hrozek wrote:
>>>> On Mon, Mar 09, 2015 at 11:52:04AM +0100, Pavel Březina wrote:
>>>>> Can we not use the ldap_ prefix since this option is supposed to be
present
>>>>> also in responder?
>>>>
>>>> Well, I don't think it should be used in the responder. I think the
>>>> responder should just request whatever it needs to and let storing the
>>>> data to cache for the Data Provider.
>>>>
>>>> What we can do is to return a DP error to make it clear that DP hit a
>>>> sizelimit and the result might be incorrect, but that's it.
>>>
>>> You can have multiple domains, therefore you want to limit both dp request
>>> and ifp request. At least this was agreed on.
>>
>> Maybe :-) I don't remember to be honest. But then I think the responder
>> and domain options should be totally independent.
>>
>> What would the responder option do precisely? Limit replies how, limit
>> how many objects are exposed on the bus? The dp request is always sent
>> to a particular domain, not all domains, right?
>
> Yes, each dp request is always sent to a particular domain.
>
> The goal is to control how many records are returned from IFP to the caller
> of FindUserByNameFilter(filter, limit).
>
> So you send dp request to all domains separately, each domain will store
> only a limited number of records. And in IFP you aggregate those records and
> return only 'limit' of them or if not set as parameter than you use limit
> from sssd.conf [ifp] section.
>
> This is what we have agreed on. We can of course change it that we will only
> obey 'limit' parameter in IFP and return all up to date records in cache.
> But then we would have to make the parameter mandatory so we don't send
> thousands of results. That would make it hardcoded in applications though...
I see and I also see why you wanted to include the same option. I already
see the split responder-provider options are a bit confusing for some
consumers in the IFP case.
So let's turn the question around -- would the domain option inherit the
responder option? With this configuration:
~~~~~~~~~~~~~~
[ifp]
wildcard_limit = 100
[
domain/example.com]
~~~~~~~~~~~~~~
Would the domain limit the wildcard request to 100 entries or just run
the full wildcard request? If not, then we can go with the shared option.
The reason I initially proposed two options is that I suspect we might
be asked to add more listing calls to the NSS responer and the
libnss_sss_idmap library in particular. If the domain should have
inherited the limit from some responder (like we do with the cache
timeouts), then which parameter do we inherit with a setup like:
~~~~~~~~~~~~~~
[ifp]
wildcard_limit = 100
[nss]
wildcard_limit = 200
[
domain/example.com]
~~~~~~~~~~~~~~
So I think we need to solve a tradeoff between using a single option and
administrators being suprised that domain searches are too wide or using
two options and then administrators being confused by two places to set
a seemigly similar option.
Sound like you prefer a single option?
Single option, no inheritance. If the option will not be present in
[domain] than a default value will be used there.