what’s next with rsyslog?

Now that we have released version 8.7.0, planning for 8.8.0 is in full force. I thought I’d share some of those things that made it to the top of the todo list:

I already have begun on some experimental research work on a pull model for rsyslog. Scenarios where that would have been extremely helpful surfaced on the mailing list and support forums since long. While never asked for violently, I think it is the time to explore that option. The first pilot implementation will probably very simplistic, but has a big impact: if it works for simple syslog, it will work for other pull protocols as well. That would open up some wholly new use cases. But be careful: it’s still unclear if and how fast we can realize such a method.

Secondly, we have receive a grant from GuardTime which enables us to improve the signature-related tooling. While this, too, is a bit of a large project, I will definitely begin to work on it in the 8.8 timeframe.

Finally, the ability to reparse messages is on the list. That’s another biggie, and it may be one that requires a handful of release cycles. To make this happen in a clean way, we need to change some of the internal interfaces as well as some of the processing philosophy. It will also need some good discussions on the mailing list.

Note well that these three topics won’t necessarily show up in 8.8, but at least they are something we strongly intend to work on – as said, I already started with the pull model.

Besides these three topics, there will be a number of minor improvements and bug fixes. I will also keep some focus on automated testing, but the most urgent need has been solved by the system I set up in Q4 2014. If all goes well, I’ll also get some inhouse help on expanding the testbench, what would be a real great plus.

That’s it for now, and as always: priorities may shift as needs arise ;)