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 _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
