[SSSD] Data dir and cwrap tests

Dmitri Pal dpal at redhat.com
Wed Dec 17 18:48:56 UTC 2014


On 12/17/2014 01:37 PM, Nikolai Kondrashov wrote:
> On 12/17/2014 08:15 PM, Dmitri Pal wrote:
>> On 12/17/2014 01:06 PM, Nikolai Kondrashov wrote:
>>> On 12/17/2014 07:37 PM, Lukas Slebodnik wrote:
>>>> On (17/12/14 19:11), Nikolai Kondrashov wrote:
>>>>> On 12/17/2014 06:44 PM, Lukas Slebodnik wrote:
>>>>>> You can use different prefix even with make check.
>>>>>
>>>>> Sure, but then it won't be just any "make check" anymore. It will 
>>>>> require a
>>>>> special "configure" invocation to work.
>>>>>
>>>>>> "make distcheck" uses it in such way. It doesn't make sense to 
>>>>>> reinvent wheel.
>>>>>> The only difference is that make distcheck does not run program. 
>>>>>> It just calls
>>>>>> "make install" and "make uninstall" (very simplified version)
>>>>>>
>>>>>> Here is simplified part of distcheck. We can use similar approach.
>>>>>>
>>>>>> distcheck: dist
>>>>>>        GZIP=$(GZIP_ENV) gzip -dc $(distdir).tar.gz | $(am__untar) 
>>>>>> ;;\
>>>>>>      chmod -R a-w $(distdir)
>>>>>>      chmod u+w $(distdir)
>>>>>>      mkdir $(distdir)/_build $(distdir)/_inst
>>>>>>      chmod a-w $(distdir)
>>>>>>      test -d $(distdir)/_build || exit 0; \
>>>>>>      dc_install_base=`$(am__cd) $(distdir)/_inst && pwd | sed -e 
>>>>>> 's,^[^:\\/]:[\\/],/,'` \
>>>>>>        && dc_destdir="$${TMPDIR-/tmp}/am-dc-$$$$/" \
>>>>>>        && am__cwd=`pwd` \
>>>>>>        && $(am__cd) $(distdir)/_build \
>>>>>>        && ../configure \
>>>>>>          $(AM_DISTCHECK_CONFIGURE_FLAGS) \
>>>>>>          $(DISTCHECK_CONFIGURE_FLAGS) \
>>>>>>          --srcdir=.. --prefix="$$dc_install_base" \
>>>>>>                                ^^^^^^^^^^^^^^^^^
>>>>>>                              custom prefix in make distcheck
>>>>>>        && $(MAKE) $(AM_MAKEFLAGS) \
>>>>>
>>>>> Yes, it invokes "configure" and does a separate build.
>>>>>
>>>>> I'm not sure what you're suggesting and I wouldn't like to guess.
>>>>> Could you please clarify?
>>>>>
>>>> It would be better to start from beginnig. You just mentioned some 
>>>> problems.
>>>> and I just wanted to give a hint not a full plan.
>>>>
>>>> You haven't mentioned your desing(proposal/plan). IMO, there are 
>>>> more ways how
>>>> to run cwrap tests. I can see what's your problem but I cannot 
>>>> image you plan.
>>>>
>>>> Could you describe (aproximatelly in ten points) what was your plan?
>>>> Then I will try fit idea from previous mail to your design.
>>>
>>> I'm not sure I'll be able to find 10 points, but here's what I'm 
>>> trying to do.
>>>
>>> I'd like to run nss/sssd/LDAP integration tests as part of a regular 
>>> "make
>>> check". I.e. not imposing any more restrictions/conditions on the 
>>> "make check"
>>> than we have now. Including running under any developer's user 
>>> account, not
>>> counting on a specific build tree location or other 
>>> files/directories being
>>> present additionally outside the build directory, and not requiring any
>>> special arguments to "make". I.e. just keep the current "make check"
>>> requirements as they are.
>>>
>>> To make that work we need the LDAP server to work with arbitrary 
>>> configuration
>>> and data locations (in our case under the build tree). OpenLDAP can 
>>> do that,
>>> with locations specified at startup time. Not sure about 389-ds.
>>>
>>> We also need all sssd components involved in the tests (at least 
>>> libnss_sss
>>> and sssd) to be able to work with arbitrary configuration, data and 
>>> socket
>>> locations (under the build tree, again). At the moment we can change 
>>> these
>>> only at the build time, via "configure" invocation.
>>>
>>> We can probably make the "check" target depend on an additional 
>>> build with
>>> changed prefix, but it feels too much of a hassle and a slowdown for 
>>> the RPM
>>> build. Making "contrib/ci/run" do the special-prefix build instead 
>>> seems
>>> easier and simpler.
>>>
>>> Nick
>>> _______________________________________________
>>> sssd-devel mailing list
>>> sssd-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>
>> If we do something in the area we should consider the config DB and 
>> config file refactoring we have on our plate anyways.
>> IMO it would make sense to pass a path to sssd.conf, directory where 
>> configuration snippets would be expected and where the cache DBs are 
>> located to SSSD as startup parameters.
>> So if they are passed they would overwrite the ones defined in the code.
>> That would help with some changes we plan to do and also with the CI.
>>
>> Would that be an option?
>
> This would help, but the libraries such as libnss_sss would need to be
> supplied the changed paths in some other way, it seems.
>
> Nick
Environment variables?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.




More information about the sssd-devel mailing list