[collectd] RFC: Should we maintain plugins written in Go?

[Ranganath, Sunku]

Good discussion, thanks for kicking this off.

> 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.
I assume you are referring this with respect to exec plugins.
If so, yes this would be great. Our team was looking for a place that can hose multiple scripts for exec plugin purposes and this would help us surely. Instead of current out-of-tree approach, this would help consolidate the scripts. Once created, would these be independent of Collectd release or would they be part of release cycle?

>   * Improve discoverability of plugins.
Could you shed some light on how you meant to appraoch this? 
Discoverability so that new plugin authors could reuse available plugins or is it more about discoverability of what plugins provide?

> On the other hand, curating a list of exec plugins is likely much less work and might also help users
Agree, this should be light weight for maintainers as the processes are in place

Thanks,
Sunku Ranganath

-----Original Message-----
From: collectd <collectd-bounces at verplant.org> On Behalf Of Florian Forster
Sent: Monday, April 27, 2020 10:34 AM
To: Matthias Runge <mrunge at matthias-runge.de>
Cc: collectd at verplant.org
Subject: Re: [collectd] RFC: Should we maintain plugins written in Go?

Hi Matthias,

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

Best regards,
—octo
--
collectd – The system statistics collection daemon
Website: http://collectd.org
GitHub:  https://github.com/collectd
Twitter: http://twitter.com/collectd

_______________________________________________
collectd mailing list
collectd at verplant.org
https://mailman.verplant.org/listinfo/collectd