[prev in list] [next in list] [prev in thread] [next in thread]
List: sssd-devel
Subject: Re: [SSSD] Data dir and cwrap tests
From: Dmitri Pal <dpal () redhat ! com>
Date: 2014-12-19 4:33:32
Message-ID: 5493AA9C.6080708 () redhat ! com
[Download RAW message or body]
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.
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic