pkg/plugins
Brian Goff b290cff825 Fix panic in loading plugins
When a plugin is first found, it is loaded into the available plugins
even though it's not activated yet.
If activation fails it is taken out of the list.
While it is in the list, other callers may see it and try to check it's
manifest. If it is not fully activated yet, the manifest will be nil and
cause a panic.

This is especially problematic for drivers that are down and have not
been activated yet.

We could just not load the plugin into the available list until it's
fully active, however that will just cause multiple of the same plugin
to attemp to be loaded.

We could check if the manifest is nil and return early (instead of
panicing on a nil manifest), but this will cause a 2nd caller to receive
a response while the first caller is still waiting, which can be
awkward.

This change uses a condition variable to handle activation (instead of
sync.Once). If the plugin is not activated, callers will all wait until
it is activated and receive a broadcast from the condition variable
signaling that it's ok to proceed, in which case we'll check if their
was an error in activation and proceed accordingly.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2016-03-23 15:34:15 -04:00
..
pluginrpc-gen Add README for pluginrpc-gen 2015-09-22 19:34:44 -04:00
transport Call plugins with custom transports. 2016-03-02 12:54:53 -05:00
client.go Fix panic in loading plugins 2016-03-23 15:34:15 -04:00
client_test.go Call plugins with custom transports. 2016-03-02 12:54:53 -05:00
discovery.go Move responsibility of ls/inspect to volume driver 2016-01-05 16:28:38 -05:00
discovery_test.go fix common misspell 2016-02-11 15:49:36 -08:00
discovery_unix_test.go Windows CI: test-unit on pkg\plugins 2016-02-10 19:28:30 -08:00
errors.go Fix some typos in comments and strings 2016-02-22 20:27:15 +01:00
plugins.go Fix panic in loading plugins 2016-03-23 15:34:15 -04:00