Plugin Interface/API Spec - working title

[geauxvirtual]

NOTE by @mjbrender: snap was originally nicknamed pulse, which is why you'll see the Pulse used below

With the discussions and suggestions of breaking plugins out into their own repos, this brings up many questions on what exactly needs to be done, and how we can keep this simple for plugin authors to write plugins for Pulse.

I feel in order to properly break plugins out from Pulse, there needs to be a defined interface/api for communications between pulsed and plugins. I think we are close to this today, but it requires multiple imports around decisions that were made when everything was in one growing repo.

Here are my thoughts and looking for comments from the rest of the team:

• There should be a single import for both pulsed and plugins
• Support versioning
• Support backwards compatibility (i.e. pulsed running latest version supports communicating with plugins not updated to latest version)

Looking for comments and other ideas. If we decide to go down this route, I see getting the code separated first for beta, with beta having the first version, then adding support for versions and backwards compatibility post beta.

[lynxbat]

Here are some ideas I had:

Pulse Plugins need to be more than a binary.

One approach is to use a manifest file which can be compressed into a tar file resulting in a plugin image.

Something like:

pulse-publisher-rabbitmq.tar
-- pulse_plugin.yaml
-- pulse-publisher-rabbitmq (binary)
-- <some signing file>
-- <other things>

Within the manifest we can have points to signing files, details on which arch the plugin was built on, etc.

Plugin Builds happen from pulsectl

We add a new subcommand for pulsectl called build. This takes parameters for signing, building, and more. It would output the full tar file writing the manifest as well are handling the go build for the plugin.

In addition we could support the pulse build command being pointed at a github.com URL for the purpose of building plugins easily. This would copy the go get behavior.

With the pulse build command we could easily bootstrap the Intel plugins hosted externally into a local build using github.com URLs.

[geauxvirtual]

Should we break this off into a separate issue as it differs from the original I put up so that we keep discussions that pertain to each separate?

ETA: Opened issue #319 with @lynxbat comment