[rsyslog] Feedback requested: inconsistency in config statements

[david at lang.hm]

On Thu, 25 Feb 2010, Rainer Gerhards wrote:

> Hi all,
>
> on Debian, a discussion came up on the inconsistency of some config
> statements. The right cure would be to correct this, but that requires some
> time. I would appreciate your feedback on the issue. The details can be found
> here:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571202

First off, the config language really has two parts.

The first part is the configuration of rsyslog, the second part is the 
instructions to rsyslog telling it what to do with the log messages it has 
received..

I think you are wildly optimistic if you think that "a year from now 
nobody will be using the old config language". I expect that 3-5 years 
from now users will still be using 3.x versions (because they are what was 
released in 'enterprise' releases)

even for new versions there will need to be a transition path (including 
the ability to easily revert to an old version)

I fully understand the desire to scrap the existing evelved config 
language and implement a new, designed version instead (without needing to 
support both), but I don't see that as being realistic.

A new designed config language should be able to have all the existing 
configs map to it, and I expect that you will have to maintain a 
shim/transition layer for many years that will read the old configs and 
map it to the new config.

for the first part of the configs (the configuration options for rsyslog 
itself, having nothing to do with processing the log messages)

As such, I think making the infrastructure to log 'this config option has 
been replaced by that config option' could actually end up cleaning things 
up and making it easier to modify the config language going forward.

If the logging of changed is done one option at a time it will be a mess, 
but if it's done as something like a mapping layer it could actually be 
better.

I'm thinking of a table along the lines of

config_option, type, destination

where type could be 'boolean', 'string', 'filesystem path', 'number', or 
'depriciated', 'ignore'

if the type is depriciated then the destination would be another 
config_option (which you would then look up)

if the type is 'ignore' then it would just be skipped over (possibly with 
a warning being logged that the config line is being ignored)

this would also clean up some of the current cases where a boolean option 
doesn't honor on/off and true/false.


For the second half of the config language (telling rsyslog what to do 
with the logs it has received) also has several variations in place and is 
showing issues.

However I think that the right answer here is to end up implementing 
something like the parsing trees and then compile the other config 
language options into that tree to be consistant (and fast) under the 
covers, no matter which way the instructions are written (except when you 
have to use regex matches)

David Lang