Implement Plugin activation

[chungers]

Currently running all the plugins by hand is not a good UX. There are also no guarantees that
all the necessary plugins are started.

We need to come up with a mechanism for starting up plugins. A couple of use cases will considered:

• plugins are deployed as locally available binaries (in the search $PATH).
• plugins are deployed as Docker containers. This case should be included because we already have support for swarm mode for things like storage and leader detection.

[wfarner]

A cheap option to consider as a straw man while figuring out the UX:

Support a file, say ~/.infrakit/config/plugins.json with shell commands for launching plugins:

{
  "group-default": "$GOPATH/src/github.com/docker/infrakit/build/infrakit-group-default"
}

The plugin discovery system could lazily try to activate plugins not already available by referring to this file and launching. Plugin activation at this layer has a nice side-effect of resuscitating plugins that exited.

[chungers]

How about making this even easier... the name referenced in the JSON is assumed to be findable in $PATH. It can be either a shell alias or an executable wrapper script.

In essence the alias / wrapper script do exactly as what you're suggesting. I think supporting a JSON file as you said is getting into supporting but we may just want to let that be the strategy used by a particular implementation? For example, if the plugins were Docker containers or engine plugins then we would have very different ways of activating plugins.

[wfarner]

How about making this even easier... the name referenced in the JSON is assumed to be findable in $PATH

👍

It can be either a shell alias or an executable wrapper script

Nit: you'd have to jump through some hoops (and likely couple to a specific shell) to get aliases to work. Relying on presence inPATH should be fine, though.

[chungers]

Implemented in #328, #356