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

[Ranganath, Sunku]

Thanks Florian for the improvements around go-collectd packages.

> 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
Being a new user to Go, have you considered 'Plugin' package of Go [3] for shared object creation? It seem to work well with existing 'C' files 
Not sure if its helpful with already available packages.

> 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
Our team were contemplating to create either an out-of-tree location or propose a new folder ourselves. So this is perfect timing for us to have this created.
Any new plugins written in Go could be hosted here.
If I understand Go correctly, new plugin authors could reuse/import any of the available Go packages from various sources and leverage go-collectd framework to make them into .SOs for Collectd daemon?

Also would it be easier to unify go plugins & go-collectd framework to something like: github.com/collectd/go-collectd/plugins?
It would be a bit confusing with github.com/collectd/go-collectd/plugin, but then atleast they both would be under same sub-tree.
May be we can rename github.com/collectd/go-collectd/plugin to something unambigous? :) 

[3] https://golang.org/pkg/plugin/

Thanks,
Sunku Ranganath

-----Original Message-----
From: collectd <collectd-bounces at verplant.org> On Behalf Of Florian Forster
Sent: Wednesday, April 22, 2020 11:29 PM
To: collectd at verplant.org
Subject: [collectd] RFC: Should we maintain plugins written in Go?

Hi everybody,

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 [0]. 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" [1] and "collectd.org/rpc" [2] 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.

Best regards,
—octo

[0] https://godoc.org/collectd.org/plugin
[1] https://godoc.org/collectd.org/exec
[2] https://godoc.org/collectd.org/rpc
--
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