[SSSD] [PATCH] nss: Preserve case of group members

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Thu Oct 2 12:56:46 UTC 2014


On 10/02/2014 03:19 PM, Michal Židek wrote:
> On 10/02/2014 01:59 PM, Nikolai Kondrashov wrote:
>> On 10/02/2014 02:09 PM, Michal Židek wrote:
>>> On 10/02/2014 10:42 AM, Nikolai Kondrashov wrote:
>>>> On 10/02/2014 12:54 AM, Lukas Slebodnik wrote:
>>>>> On (01/10/14 20:19), Nikolai Kondrashov wrote:
>>>>>> On 10/01/2014 06:33 PM, Jakub Hrozek wrote:
>>>>>>> On Wed, Oct 01, 2014 at 04:58:37PM +0200, Pavel Reichl wrote:
>>>>>>>>
>>>>>>>> On 10/01/2014 04:09 PM, Michal Židek wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> see attached simple patch that fixes ticket:
>>>>>>>>> https://fedorahosted.org/sssd/ticket/2453
>>>>>>>>>
>>>>>>>>> Michal
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Patch fixes the problem. ACK
>>>>>>>
>>>>>>> * master: f6e008fe677ffcf8781c1d5154544066ea7ca9d4
>>>>>>
>>>>>> A CI job for this commit has failed on Debian:
>>>>>> http://sssd-ci.duckdns.org/logs/job/1/22/summary.html
>>>>>>
>>>>>> in test-negcache test:
>>>>>> http://sssd-ci.duckdns.org/logs/job/1/22/debian_testing/ci-build-debug/test-negcache.log
>>>>>>
>>>>>>
>>>>>>
>>>>>> Nick
>>>>> Works for me without any problem on clean, minimal, up to date
>>>>> installation of
>>>>> debian-jessie and ubuntu 14.04.
>>>>
>>>> Yes, it was probably a non-reproducible "fluke", but it's worth being
>>>> aware
>>>> of. I haven't seen it fail ever before.
>>>
>>> It looks like the execution of the test slowed
>>> down (was paused or whatever) and the negative cache expired.
>>> Maybe the VM did not have enough resources from the host and
>>> slowed down execution. Or some other random strangeness.
>>
>> Ah, thank you Michal. It then joins the dyndns test (and some other) in the
>> group of timing-dependent tests. We'll have to do something about these.
>> The
>> VM environment load is not very predictable and it's better not to have
>> randomly-failing tests in CI for whatever reason. Can we somehow
>> increase the
>> time window size for them, perhaps?
>
> Increasing the time window is possible. It is currently set to
> one second in the tests. If it fails in the future again, we
> can double it. But one second should be really a lot for what
> it does so I would keep it as is for now.

Sure, let's see how it goes, thank you.

I see dyndns failures much more often, do you know if we can do anything about
that?

Nick



More information about the sssd-devel mailing list