configuration directory

[AL13N]

> 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.

haha, i did my code in 2 lunchbreaks too :-). i suppose it's some kind of
git branch, i'll look into it.

>> 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.

ah, so that's the point... even more refactor work :-)


the problem we're gonna face here is that

char *config_file;
char *config_file_dir;

are exported symbols...

how are we gonna make this work without changing those exported symbols?
so that nagios addons will still work?


------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk