On 2013-09-13 12:07, AL13N wrote:
>> On 2013-09-13 11:15, AL13N wrote:
>>>> On 2013-09-12 13:33, AL13N wrote:
>>>>> This should be a patch for
>>>>> A) allowing multiple main config files
>>>>>
>>>>> i haven't compiled/run/tested this yet, but this is the kind of thing
>>>>> i
>>>>> thought would be good.
>>>>>
>>>>> can someone please tell me if i'm working in the right direction or
>>>>> not?
>>>>>
>>>>
>>>> Sort of, and then again, no. It would be good if, as a first step, we
>>>> read all main-config-parameters from read_main_config_file() (or some
>>>> other function which just groks key/value pairs that gets fed by one
>>>> or more invocations of read_main_config_file()).
>>>>
>>>> That way the patch wouldn't have to fiddle with object config reading,
>>>> which won't work properly unless you also add multi-config support to
>>>> read_object_config_files().
>>>
>>> but, that's the way it's written now... we'd have to refactor the way
>>> the
>>> config files are read, and then the patch would be quite invasive,
>>> wouldn't it?
>>>
>>> did you see the 2nd patch? where i added multi-config support for
>>> read_object_config_files? (or at least very basic, i didn't check if
>>> these
>>> functions reset some internal variables at the start of their call)
>>>
>>
>> Ah, no, I didn't.
>>
>>>
>>> what exactly are you thinking of doing?
>>>
>>
>> All the "initialize this" and "read_object_config_data()" only parse
>> a few variables out of the main config file(s) and then set a few
>> variables based on values found there. I would much prefer to have
>> config variables read in a single place, all the variables properly
>> set based on the latest parsed value (last in wins the race, basically),
>> and then calling the init functions while removing the config file
>> argument to them completely.
>
> yes, that does seem better, but that's quite some refactoring... i guess
> if you insist, we'll have to do this one first...
>
I've been meaning to do that for some time anyway, and I actually
started it with bf64caf4f2876b1377df08e9fa4c439d5562fdbb. The code
that remains is the one I couldn't convert in a lunchbreak. At least
if I wanted to eat something as well.
> combined with that, there's the added problem of config_file_dir where the
> dir of the main config file is used for whatever default directory.
>
> i had to have a main config file and extra config files, if we get to
> directories, the first main config will not be able to be used...
>
Well, paths found in config files should be relative to the config file
the path was parsed from. Adding a helper to lib/nspath.c to get that
based on a full path to a file would probably be the best solution.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: ae@op5.se