Hi David, thanks for the thoughtful comments. But I seem to have incorrectly phrased my question, leaving out too many of those things that I obviously took for granted and thus not mentioned :(...
> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Sunday, February 28, 2010 1:45 AM > To: rsyslog-users > Subject: Re: [rsyslog] Feedback requested: inconsistency in config > statements > > 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) > That was probably the most important thing I did not mention: I do NOT think that removing inconsistencies in the config language is a bug fix. And if it is not a bug fix, it is a feature request. But if it is a feature request, it will go into the recent devel. And as such it will be a v5-exclusive thing. As such, what is with v3 and v4 doesn't really matter, because it would not be changed (and, yes, I totally agree that v3/3 will be around for a long time). One may argue if this feature is so essential that it should be rolled back into the old versions. However, I became very skeptic of doing so. Almost always in the past years, when I put some non-essential change into the stable releases directly, big problems were the result. I could probably open up new devel/beta branches for v3/v4 as well. But that would a) cause a lot of extra work b) people would most probably not try it out so we would end up with the same issue when it is then named stable c) the experience with two v4/v5 devel versions was a bad one as well. It is too easy to mix up where the regression is And now to the time slot: I guess, when a clean config language is there, most people would tend to use the new format. This is why I assumed that after a year the old language (in v5!) will most probably not be used much longer. To be precise, I fear that I take out time to implement this in v5, then have the new format (let's hope) 6 month later available then wonder if that would really make a difference over not doing the first step. If I had lots of time, it would probably still make sense. But unfortunately, I currently have far less time than I wish I had. Thankfully, the newer versions get more and more adopted, but that also means more bug fixes to do. So I sadly see that my available time is currently eaten up by those bug fixes and clarifying things inside the doc so that people can use the features. That is almost painful to me, because I have so many cool things on my mind, but do not find time to implement a single one of them :( > 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. The new config language doesn't mean that the old will no longer work. It is a primary design goal to support both in parallel. I always tried hard to make rsyslog as backwards-compatible as possible and it turns out that this is a major advantage, at least at the low end. I do not intend to drop that (one need also consider existing know-how: people should be able to get rsyslog immediately up and running, for simple cases, without the need to learn anything new). > > 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' This *is* how the system works today! But I don't have a deprecated flag and aliases, so I would need to rewrite that whole system. BTW: this system is the reason why I avoided writing a new system until absolutely necessary: it is too easy to add a new directive as all you need to do is add a new "table entry". > > 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. True/false is NOT a valid boolean option. See http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/cfsysline.c;h=184c0d87 47c5dcbbd8230782ca096e477738efa9;hb=HEAD#l308 > > > 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) I don't fully agree here with you. For example, the traditional PRI based filter is lightning fast. I don't see any way it could be nearly as fast with any unified approach. Right now, we have a "unified" filter structure, but it contains three filter cases, each one adding potential power at the price of decreased speed. I think we need to keep different types of filters in order to have some lightning-fast ones. But more of this could be done under the hood. Rainer > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
