[collectd] RFC: Should we maintain plugins written in Go?
krzysztof.kepka at intel.com
Mon Apr 27 09:18:40 CEST 2020
Thank you for bringing this up and all the improvements Florian!
Golang seems to gain more popularity for quite a lot cloud native software, it makes sense to have this type of plugins integrated well. I'm sure there will be interest in contributing to those.
I like the idea you have described below with central community repository, with similar thoughts around.
From: collectd <collectd-bounces at verplant.org> On Behalf Of Nick Babcock
Sent: Saturday, April 25, 2020 10:23 PM
To: collectd at verplant.org
Subject: Re: [collectd] RFC: Should we maintain plugins written in Go?
I think it makes sense to support Go plugins. While I can't speak about Go directly, maintaining a Rust crate  for creating collectd plugins over the years has taught me that there are some benefits to out-of-band plugins compiled to shared objects:
- More rapid plugin releases (especially new plugins) that don't need to be tied to the main release
- Being able to have a plugin target collectd versions prior to its existent. For instance, the rust crate allows one to compile to a shared object that is compatible with either 5.4, 5.5, or 5.7+'s collectd plugin API. So in effect, new plugins can be backported to older collectd installations.
I don't know if those are in accordance with your thoughts, but I feel like allowing Go plugins could also lower the barrier to entry for contributors.
From: collectd <collectd-bounces at verplant.org<mailto:collectd-bounces at verplant.org>> on behalf of Florian Forster <octo at collectd.org<mailto:octo at collectd.org>>
Sent: Thursday, April 23, 2020 1:29 AM
To: collectd at verplant.org<mailto:collectd at verplant.org> <collectd at verplant.org<mailto:collectd at verplant.org>>
Subject: [collectd] RFC: Should we maintain plugins written in Go?
TL,DR: Should we create a new Git repository and maintain plugins
written in the "Go" programming language?
the last days, I spent some time improving the "collectd.org/plugin"
package . In a nutshell, it allows to implement a plugin in Go,
compile it to a shared object and then load it like other "native"
(implemented in C) plugins. The primary benefit over approaches such as
the "collectd.org/exec"  and "collectd.org/rpc"  packages is, that
it supports implementing "write" and "log" callbacks. "config"
callbacks, allowing one to configure the plugin via the collectd config
file, are work in progress.
My question is: Should we attempt to maintain plugins written in Go? And
if so, how?
For Go-based plugins, i.e. plugins based on "collectd.org/plugin", I
propose we create a separate repository, e.g.
github.com/collectd/go-plugins, and maintain those there. This would
make plugins easier to discover for users, allow easier changes to the
API, and strive for consistency across the ecosystem.
In the past, we have imported plugins in non-C languages into the main
repository, in particular bindings/perl/ and bindings/java/. This model
is not a good fit for Go, which makes much more assumptions about the
directory structure of a repository. Also, for Perl and Java the "glue
code" (code translating between Perl and Java, and C) is contained in
the "main" reposiroty; that's not the case for Go.
I'm also contemplating if we should try to support plugins using the
"exec plugin" more, e.g. by creating a repository for them. There are a
number of "collectd Docker" plugins and I feel like this duplication
could have been avoided by better discoverability.
collectd - The system statistics collection daemon
collectd mailing list
collectd at verplant.org<mailto:collectd at verplant.org>
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the collectd