[SSSD] Data dir and cwrap tests

Lukas Slebodnik lslebodn at redhat.com
Thu Dec 18 23:34:00 UTC 2014


On (17/12/14 20:06), 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.
I agree with restrictions/conditions.

>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.
OpenLDAP is good enough for cwrap test. 389-ds can be used for real
integration testing. Do you have a plan to include kdc to cwrap tests?
It can be implemented in 2nd round of cwrap tests.

Everything sounds good but I was more interested about details related to
cwrap tests. Will it be just one test or more tests?
Because make uses "Parallel Test Harness" [1] and there can be problem with
shared ldap server.

How will be done setup/teardown of OpenLDAP/SSSD (pytest?)

>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.
The initial configure could be executed with custom prefix in CI
but it would not work for developer use case. It might not be a solution.

Even that extra configure has some overhead it seems to be the fastest &
easiest way how to implement cwrap test. It can be improved in future.
On my machine, it took 20 seconds (configure && make install).
I think we can live with this and my expectation is that tests will take
longer.

If we want to "limit" overhead for regular usage then we can separate
unit tests and cwrap test. Unit tests will be executed by default with
"make check" and cwrap test only in case of enabled special variable
"make check CWRAP=yes" (I dind't test it) or we can use different make
target "make cwrap-check"

Some ideas can be modified. It depends on answer about organization of setup,
teardown ...

LS

[1] http://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html



More information about the sssd-devel mailing list