[SSSD] Data dir and cwrap tests

Jakub Hrozek jhrozek at redhat.com
Mon Jan 5 14:46:06 UTC 2015


On Thu, Dec 18, 2014 at 11:33:32PM -0500, Dmitri Pal wrote:
> On 12/18/2014 05:54 PM, Lukas Slebodnik wrote:
> >On (18/12/14 09:27), Dmitri Pal wrote:
> >>On 12/18/2014 06:17 AM, 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
> >>>>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?
> >We can file a ticket if we don't want to forget about this idea.
> >The question is when it will be implemented in sssd. Therefore we need to use
> >different approach for cwrap test. As a result of this ticket can be moved to
> >deffered bucket.
> >
> >>>How close would you say is this?
> >>I hope it will be done in 1.13 but I am not sure. It all depends on how much
> >>I will be able to do over the break.
> >>
> >>>Shall I help push it, or make cwrap tests
> >>>work outside "make check", within "contrib/ci/run" instead first?
> >>Let us start with static paths and build time prefix for now but keep this in
> >>mind.
> >Agree.
> >
> >>>BTW, would we really need a separate parameter for configuration snippet
> >>>directory? Can't we have them relative to the top-level sssd-conf?
> >>This is really an SSSD call. I would argue that SSSD should probably have a
> >>startup parameter that would be a list of directories to use. Something like:
> >>-D dir1 -D dir2
> >>Or something similar.
> >It hasn't been implemented yet :-) but it's good idea.
> >
> >LS
> Can you please file the corresponding tickets?

Nikolai, can you file a ticket as part of your CI design page work?
Thank you!

btw I personally don't mind using an environment variable here, but a
command line switch would be possible as well, as long as it's ommited
from the --help output.



More information about the sssd-devel mailing list