plugins hooked into cmd/ocagent

[odeke-em]

Also added a canonical example as well as
regression test to ensure that plugins
work as expected.

This change finishes up the work started in #46.

Fixes #47

[odeke-em]

Travis doesn't seem to be returning the proper path of the Go binary that it used to run the current binary.

[songy23]

Please fix the build.

EDIT: looks like ./cmd/ocagent/plugins/plugins_test.go is not formatted correctly?

[odeke-em]

EDIT: looks like ./cmd/ocagent/plugins/plugins_test.go is not formatted correctly?

Thanks! But the change I made it to didn't affect the functionality, so the Travis Go binary still doesn't seem to be found.

[odeke-em]

The test when run locally passes but on Travis

	plugins_test.go:82: Unexpected output: 2018/10/08 21:00:19 Failed to load the plugin from
/tmp/plugin_end_to_end889768309/sample.so Error: plugin.Open("/tmp/plugin_end_to_end889768309/sample"): plugin was built with a different version of package sync/atomic

It is just an integration/example test that can be run on a proper setup so am going to skip it for now, as it is a nice to have.

[odeke-em]

@songy23 PTAL.

[songy23]

The logic makes sense to me, though I'm not very familiar with the syntax/usage of Go plugins. /cc @rakyll on this change.

[rakyll]

Please don't use Go plugins yet. They are not production ready and are not supported on Windows.

[odeke-em]

Please don't use Go plugins yet. They are not production ready and are not supported on Windows.

@rakyll yes, we considered that as per https://github.com/census-instrumentation/opencensus-service/blob/master/exporter/plugins.md#limitations
and in the proposal issue #47

They are not production ready

What do you mean?

[rakyll]

What do you mean?

There are many missing pieces. For example, if a plugin is built by a different version of Go, it cannot be loaded to a binary built with a different version. There are problems with sharing data and using types from third party packages. Plugins are not currently ready to be used for the purposes we want them be used for. Even if we use plugins, we need to own and build the vendor-specific shared libraries each time we make a new binary release.

[odeke-em]

There are many missing pieces. For example, if a plugin is built by a different version of Go, it cannot be loaded to a binary built with a different version.

Also considered and in the limitations section of https://github.com/census-instrumentation/opencensus-service/blob/master/exporter/plugins.md#limitations

Even if we use plugins, we need to own and build the vendor-specific shared libraries each time we make a new binary release.

Not really, we plan on distributing say binaries or a Docker image built using a specific version of Go that will be returned by #60 and vendors can hook into.

Plugins are not currently ready to be used for the purposes we want them be used for.

Our purpose here is very specific and we cut through the limitations mentioned, please correct me if am missing something else but I believe we examined all those points raised.

[rakyll]

Our purpose here is very specific and we cut through the limitations mentioned, please correct me if am missing something else but I believe we examined all those points raised.

We can achieve agent features without having to rely on plugins. For example, we can look in the PATH if a vendor-specific agent extension binary exists.

If config file contains "apmvendor", we can look whether ocagent-apmvendor is in the PATH and fork it. Then communicate from ocagent to ocagent-apmvendor for exports. I am sure there are more other alternatives but this is one of the possibilities.

[rakyll]

The other alternative is to make ocagent server a library, so vendors can build their own ocagent-compatible binaries with their features and exporters and distribute them without having to rely on us.

[derekperkins]

+1 to not using native Go plugins. This is a more production ready option if you keep going down the plugin path https://github.com/hashicorp/go-plugin

[bogdandrutu]

As we discussed I think it is important to achieve the flexibility and configurability for the agent but I think plugins are not good here because they are not very mature and they don't work on windows based on my understanding.

[odeke-em]

+1 to not using native Go plugins. This is a more production ready option if you keep going down the plugin path https://github.com/hashicorp/go-plugin

@derekperkins nice suggestion! However, please take a look (if you haven't already) at https://github.com/hashicorp/go-plugin#what-about-shared-libraries for the reason why they wrote that library in 2012 and then compare to today :)

As we discussed I think it is important to achieve the flexibility and configurability for the agent but I think plugins are not good here because they are not very mature and they don't work on windows based on my understanding.

@bogdandrutu sort of: they've been around since 2012 and not working on Windows is something we discussed and documented, plus I answered all the points raised in #70 (comment)

I think this proposal can simmer for a while as we find other ideas, as suggested. It is great that we've gotten discourse from this implementation and for now we can develop the other features of the agent until someone actually needs this feature or prioritize it. Thanks y'all!

[derekperkins]

nice suggestion! However, please take a look (if you haven't already) at https://github.com/hashicorp/go-plugin#what-about-shared-libraries for the reason why they wrote that library in 2012 and then compare to today :)

Honestly I don't think the situation has changed much since 2012. Not only do Go versions have to match, but there are serious issues with shared libraries, vendoring and versioning like @rakyll mentioned. golang/go#20481

If the question is about performance, another route is something akin to the plugin system for Caddy. https://caddyserver.com/download That actually natively compiles supported plugins into a binary.

I think this proposal can simmer for a while as we find other ideas, as suggested

sounds like a plan :)

[odeke-em]

I'll close this PR and if we need it back, we can get it back from history.

[yurishkuro]

A better link to Caddy plugins approach: https://github.com/mholt/caddy/wiki. As I understand, it's just adding the plugins to the source code and building a custom binary, i.e. does not involve distributing pre-built binaries for core server + plugins.