[collectd] RFC: Should we maintain plugins written in Go?
octo at collectd.org
Mon Apr 27 19:34:29 CEST 2020
On 2020-04-27 10:08, Matthias Runge wrote:
> While I also like the idea to provide a "repository" for exec plugins,
> or a list of exec plugins, I wonder if we would like to add any
> limitations? Would we "support" an exec plugin written in scheme? What
> would it mean, if a plugin is included in the repository. Would we care
> about it? Would we fix a bug, a CVE?
all excellent questions.
My goals would be:
* Review the naming schema of metrics. This is something that new
plugin authors often get wrong.
* Establish best practices, such as "script requiring root privileges
sudo's itself if necessary".
* Improve discoverability of plugins.
* Provide a CI/CD pipeline and possibly a release process, so that
individual plugin authors don't need to.
The first two require involvement from someone on the team, mostly for
reviews. Once reviewed, I'd consider to give commit access *for that
repository* to the contributor, so they can maintain their plugin
unilaterally, i.e. without further code reviews.
The last point (CI/CD piperline) is arguably the most language-dependent
and work intensive. I guess it would be reasonable to draw a line
somewhere, though I'm not sure where it would be. That said, most
plugins I've seen in the wild didn't use "unusual" languages – they were
mostly in Bash, Python, and Ruby.
On the other hand, curating a list of exec plugins is likely much less
work and might also help users. For reference, a (very imcomplete) list
is here: https://collectd.org/wiki/index.php/Category:Exec_Plugins
collectd – The system statistics collection daemon
More information about the collectd