A snap plugin can be in a Loaded
or Running
state. A plugin can be loaded
in the following two ways.
snapd
was started with an auto discover pathsnapd -a /etc/snapd/plugins
- A user loads a plugin through the REST API or using the snapctl
curl -F file=@snap-plugin-publisher-file http://localhost:9191/v1/plugins
snapctl plugin load snap-plugin-publisher-file
A plugin transitions to a running
state when a task is started that uses the
plugin. This is also called a plugin subscription.
When a plugin is loaded snapd takes the following steps.
- Handshakes with the plugin by reading it's stdout
- Updates the metric catalog by calling the plugin over RPC
GetMetricTypes
returns the metrics the plugin providesGetConfigPolicy
returns the conf policy that the plugin needs
- The plugin is stopped
It should be emphasized that when a plugin is loaded it is started but stopped as soon as the metric catalog has been updated.
When a plugin is unloaded snapd removes it from the metric catalog and running instances of the plugin are stopped.
When a task is started the plugins that the task references are started and subscribed to. The following steps are taken when a task is created and started.
- On task creation the task is validated (
snapctl task create -t mytask.yml --no-start
)- The schedule is validated
- The config provided for the metrics (collectors), processors and publishers are validated
- On task starting the plugins are started (
snapctl task start <TASK_ID>
) - Subscriptions for each plugin referenced by the task are incremented
Task started - When a task is started the plugins which are referenced by the task manifest are subscribed to and a 'subscription group' is created. A 'subscription group' is a view that contains an ID, the requested metrics, plugins and configuration provided in the workflow.
Task stopped - When a task is stopped the plugins referenced by the subscription group are unsubscribed and the subscription group is removed.
Plugin loaded/unloaded - When a plugin is loaded or unloaded the event triggers processing of all subscription groups. When a subscription group is processed the requested metrics are evaluated and mapped to collector plugins. The required plugins are compared with the previous state of the subscription group triggering the appropriate subscribe or unsubscribe calls. Finally the subscription group view is updated with the current plugin dependencies and the metrics that will be collected based on the requested metrics (query).
CollectMetrics - When a task fires and CollectMetrics is called the subscriptionGroup is used to lookup up the plugins that will be called to ultimately perform the collection.