Plugins

Nodewatch is designed to provide a practical degree of segregation between end-user modules, referred to hereafter as plugins, and core system functionality. This separation is applied by keeping many concerns internal to Nodewatch.

Process Supervision

This is an obvious one - Nodewatch manages process supervision internally. User defined plugins and other extensibility mechanisms can participate in supervision trees, by exporting the relevant process configuration.

Remote Code Loading

Nodewatch delegates to the eper OTP library to deal with remote loading beam code and many other aspects of its interaction with target nodes. These mechanisms are not (currently) customisable, and plugin authors should work on the assumption that their code will be loaded onto remote nodes for them.

Scatter/Gather

Nodewatch deals with gathering data from sensors and publishing to relevant sink-interfaces. Nodewatch provides APIs to manage both these elements, as well as potential connections between them.

Authoring Plugins

The only non-functional concern that plugin authors must deal with, is the need to export the requisite configuration data upon which Nodewatch relies. Instructions for exporting sensor and interface configuration data are available on the wiki - go ahead and follow the links.

Some configuration data is used for both kinds of plugin, and may be exposed to administrators via the configuration management API. Where noted, configuration data will also be discoverable via the configuration management API. All these configurations items are mandatory, unless otherwise stated.

Tag	Description	Discoverable	(API) Managed?
name	The name of the plugin.	true	false
description	A short description of the plugin.	true	false
org	The providing organisation (where applicable) or author.	true	false
enabled	Whether or not the plugin is enabled for use.	true	true
external	Optional. Whether the plugin runs externally (to Nodewatch).	true	false

Using Internal APIs

Plugins being compiled against Nodewatch, will obviously have access to internal modules. Authors are advised to stick to the following guidelines when using Nodewatch internals.

Library/Application	Module	Can be used?
*	*	Do not use internal Nodewatch modules in sensors. They will not be on the code path.
dxcommon	*	Yes (from sink-interfaces).
dxdb	dxdb	Yes (from sink-interfaces), but only for read-only operations.
dxkit	dxkit	Yes (from sink-interfaces).

Provision may be made at a later stage, for exposing some Nodewatch modules to remote loaded plugins (i.e., sensors).

Getting Help

All Nodewatch’s internal sensors and interfaces are implemented as plugins. The source code for built in modules is therefore a perfect reference for implementors.

There is an FAQ page maintained at https://github.com/hyperthunk/nodewatch/wiki/FAQ, and any concerns, questions, bugs or other issues can be raised on https://github.com/hyperthunk/nodewatch/issues.