Plugin life cycle
A Snap plugin can be in a
Running state. A plugin can be loaded
in the following two ways.
snapteldwas started with an auto discover path
snapteld -a /opt/snap/plugins
- A user loads a plugin through the REST API or using the snaptel
curl -F file=@snap-plugin-publisher-file http://localhost:9191/v1/plugins
snaptel 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.
What happens when a plugin is loaded
When a plugin is loaded snapteld takes the following steps.
- Handshakes with the plugin by reading it's stdout
- Updates the metric catalog by calling the plugin over RPC
GetMetricTypesreturns the metrics the plugin provides
GetConfigPolicyreturns 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.
What happens when a plugin is unloaded
When a plugin is unloaded snapteld removes it from the metric catalog and running instances of the plugin are stopped.
What happens when a task is started
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 (
snaptel 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 (
snaptel 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.