[SSSD] Design discussion: Wildcard Data Provider requests

Pavel Březina pbrezina at redhat.com
Tue Mar 10 09:18:23 UTC 2015


On 03/09/2015 02:21 PM, Jakub Hrozek wrote:
> 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.




More information about the sssd-devel mailing list