Thanks David for your thoughts. > one reason why so many things have been in different modules is to reduce the > footprint of rsyslog. As all systems (including embedded) have had storage > grow > a lot, we may want to consider including more by default, even if they bring > in > some additional dependencies > > We would need to proceed carefully, pulling in liblognorm by default is not > that > big a deal, but we don't want to accidently trigger the install of PostgreSQL > accidently by including a module that can write to it :-)
That's definitely not something that we want to do. The modules I have on my mind use almost only plumbing that is available in rsyslog core anyhow, and just add some lightweight (but heavy from a usage PoV) processing on top of it. The notable exception is yaml, where we currently have no support in the core. Adding it may drag more components in than I currently envision. As far as I know, libyaml is a stand-alone lib, and so it should be "not too much". > > At the same time, all these module binaries are pretty small. So it > > may make sense to include them directly in the base package. Pro is > > also that it enhances usability because it is always present (a > > typical complaint from rsyslog users is that they need to install > > additional component packages). > > what is the difference in both size and performance in having these as > separate > module binaries vs a thin shim layer over liblognorm/mmnormalize? (my guess is > tht the direct implementation is faster, and not significantly larger, if at > all) I hope Michael can share his PoV here - I am not really qualified to answer that. But I know that in the past we had discussions every now and then that "the metadata is larger than the module footprint, and metadata is downloaded in any case". Not sure if that still applies - or was even correct in the first place ;-) > > As a lightly related side note, yaml config-type artefacts are also > > being much requested. We are thinking hard to support this, at least > > in some places (upcoming enhancements to mmjsonparse for schema > > transformation might be such a place). > > more info on this please? See https://github.com/rsyslog/rsyslog/issues/6251 for an example. (yaml on mailing list gives chaos ;)) In the long term, I could also envison that a rsyslog configuration could be expressed in yaml (give it a rsyslog.yaml vs. rsyslog.conf). Many folks nowadays love that way to config, and for most parts there is a simple one to one mapping to existing modern config syntax. > yes, things change, and the easier it is to use rsyslog out-of-the-box without > having to figure out a bunch of other packages to load the better. I think we > may have gone slightly overboard in our efforts to keep the core small and not > include any modules that needed other libraries. Yeah - and as you say; times AND constraints have changed. > We should keep compile time options to turn off modules (and their > dependencies) > for embedded use, but for more powerful systems, the overhead of dealing with > that reduces or eliminates the savings. full ack, but compile time options are ugly as you cannot build a single set of packages. Maybe, if that makes sense, a rsyslog-minimal package without these components (like often done in container images). Thanks again for your feedback everyone. Looking forward to more. Rainer _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
