[Freeipa-devel] Using JSON for tlog config files

[Martin Kosek]

Removing the secondary list from this discussion.

On 06/15/2016 01:29 PM, Nikolai Kondrashov wrote:
> Hi Simo,
> 
> On 06/15/2016 12:25 AM, Simo Sorce wrote:
>> On Tue, 2016-06-14 at 16:40 +0300, Nikolai Kondrashov wrote:
>>> Although this was mentioned several times before, I'd like to bring additional
>>> attention to the idea of using config files written in JSON for tlog, because
>>> there were some concerns over that being appropriate.
>>
>> What was the reasoning behind this questioning ?
> 
> The concern that JSON in those files might be inconvenient for administrators.
> 
>> In order to understand whether json is appropriate I need to ask who do
>> you think will be the primary user of the configuration file.
>> - Is it going to be mainly sysadmins manually setting things up ?
> 
> At first, yes. Later minimally, because we plan to implement central control
> of most (if not all) of the parameters.

Yes, but AFAIK, tlog will still also exist as standalone component and could be
configured without integration with FreeIPA. This means admins main
configuration file would still be the config file.

> The suggestions so far were to have
> the same JSON simply stored in HBAC-bound LDAP entries verbatim. Although, I'm
> not sure if that would be best.
> 
>> - Is this going to be something that may need to be templated and
>> delivered via things like puppet ansible ?
> 
> I didn't plan specifically for that. I expect the chances of that are about
> the same as for any other config file.
> 
>> - Is it going to be a file generated by some other program (like sssd or
>> similar) based on rules stored in a central system ?
> 
> I'd like to avoid requiring any program controlling tlog to write any files.
> That's why I implemented passing the whole or part of the configuration via an
> environment variable value, overriding the global config. However, yes, that
> value is expected to be the same JSON at the moment.
> 
>> The answer to these questions will help understanding what format is
>> better suited.
> 
> Thanks, Simo!
> 
> Nick
>