[SSSD] Closing Ticket #2045

Jakub Hrozek jhrozek at redhat.com
Thu Jul 3 20:42:13 UTC 2014


On 03 Jul 2014, at 19:05, Michal Židek <mzidek at redhat.com> wrote:

> On 07/03/2014 05:34 PM, Jakub Hrozek wrote:
>> On Thu, Jul 03, 2014 at 05:01:54PM +0200, Michal Židek wrote:
>>> Hi,
>>> 
>>> this ticket: https://fedorahosted.org/sssd/ticket/2045
>>> (Create a test that corrupts the memcache)
>>> is no longer valid. We intended to create this
>>> test to figure out what is wrong with the memcache
>>> when it randomly segfaulted in the past and we
>>> could not reproduce it.
>>> 
>>> But the segfaults were later fixed by Lukas's patches
>>> and so the investigation is no longer needed (Lukas
>>> was actually able to reproduce it with a stress test).
>> 
>> Was the stress test something we can eventually upstream (eg a unit
>> test) or was it exercising the whole sssd?
>> 
>> If the latter, then such test would be a candidate for CI..
>> 
> 
> IIRC it was not a unit test, but a modified SSSD build with
> smaller memory caches. Then getent was called in a loop for several
> hours (for diffrent users, so that the cache had to reuse
> the space to store new entries) until it crashed. But
> Lukas will know better. In general I would welcome stress
> tests in our upstream test suite.
> 

Me too, but frankly the memcache has already been hardened in downstream.  That doesn’t mean we shouldn’t develop tests for it at all, but I think we should spend time on developing tests for code we change. 

So my suggestion is to close the ticket you referenced and creating another one to cover the memcache with unit tests. The new ticket would either be picked up during a dedicated effort to develop more tests (I’m not holding my breath for that, though) or as part of any changes to the memcache code, such as adding support for more maps.

At the same time, I would encourage other patch reviewers to be more strict in requesting unit tests along with code submissions. I’ve been trying to get more evil in this respect myself lately :-)

Do you agree?


More information about the sssd-devel mailing list