configuration directory

Andreas Ericsson ae at op5.se
Fri Sep 13 17:39:24 CEST 2013


On 2013-09-13 12:44, AL13N wrote:
>> 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?
>

They can remain as is, and point to the first config file (which will
remain the "main" config file). I doubt very many use them though, and
the parsed variables (such as object config files) should be kept as an
array for modules that want to do something with them. Currently only
Merlin does, and I'm the maintainer there, so I'll make sure I can check
for it somehow.

-- 
Andreas Ericsson                   andreas.ericsson at 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.

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




More information about the Developers mailing list