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.