On Mon, Jan 05, 2015 at 11:05:07PM +0200, 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
If you think config options are better, then fine. It's not like showing
the db or socket dirs in the "ps" output reveals some secrets :-)