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?
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.