On 01/05/2015 04:05 PM, Nikolai Kondrashov wrote:
On 01/05/2015 10:57 PM, Dmitri Pal wrote:
> On 01/05/2015 03:45 PM, Nikolai Kondrashov wrote:
>> On 01/05/2015 04:46 PM, Jakub Hrozek wrote:
>>> 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:
>>>>>>>> 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.
>>>>>
>>>> Can you please file the corresponding tickets?
>>>
>>> Nikolai, can you file a ticket as part of your CI design page work?
>>> Thank you!
>>
>> I'm not sure this is related to CI design much. Rather to config
>> splitting
>> implementation.
>>
>> I think here Dmitri is requesting a ticket for implementing sssd
>> options
>> specifying directories to store configuration snippets to be merged
>> with the
>> main sssd.conf. I can file it, but maybe someone who's better aware
>> of the
>> splitting/merging design will be more suitable.
>>
>>> 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.
>>
>> Um, I think there is some confusion here.
>>
>> I think Dmitri suggested adding command line options to support
>> specifying
>> database and socket locations (see the top quote). Personally, I think
>> configuration file options would be more appropriate.
>
> It then becomes a chicken and egg problem. Config file options to
> specify
> where the config file should be found does not help much. It should be
> either an environment variable or a startup argument.
Um, I'm talking about this piece:
> 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.
Particularly, about the cache DBs location. Also socket locations that
you
didn't mention. I understand that we can't specify location of the
configuration file in the file itself.
I.e. it's the alternative of having (roughly) these in sssd options:
--db-dir=DIR Database directory.
--socket-dir=DIR Socket directory.
Or having these in sssd.conf:
db_dir (string)
Database directory
socket_dir (string)
Socket directory
It can be a single option instead, probably.
Nick
This makes sense but I think it would be quite hard to do.
The configuration would have to be read and processd before some of the
other things. I am not sure it is currently the case.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.