Jump to: navigation, search

Difference between revisions of "Satori/PluginsProposal"

m (Built-in plugins)
m (Built-in plugins)
 
Line 18: Line 18:
 
* DNS: we verify that  a name resolves and obtain whois information. This applies to any DNS-registered name and all providers.
 
* DNS: we verify that  a name resolves and obtain whois information. This applies to any DNS-registered name and all providers.
 
* SSL certificates: we check certificate validity, expiration, and revocation lists. These checks again apply to any provider.
 
* SSL certificates: we check certificate validity, expiration, and revocation lists. These checks again apply to any provider.
OpenStack Infrastructure: as an OpenStack-focused "related" project, we're going to include these as built-in plugins.
+
* OpenStack Infrastructure: as an OpenStack-focused "related" project, we're going to include these as built-in plugins.
  
 
==== Contributed plugins ====
 
==== Contributed plugins ====

Latest revision as of 18:36, 27 February 2014

Why?

We're looking to implement in-host discovery where we log on to machines and run a process on them that retrieves information about what is installed and running on them.

We'd like remain relatively agnostic about what tools these should be (i.e. not favor ohai over facter over devstructure/blueprint), so a method of making them dynamically loadable is required.

Types of Plugins

We think there are three categories of plugins to support:

1. Built-in plugins

2. Contributed plugins

3. External plugins

Built-in plugins

These are part of the core satori code and generic enough to apply everywhere. Examples are:

  • DNS: we verify that a name resolves and obtain whois information. This applies to any DNS-registered name and all providers.
  • SSL certificates: we check certificate validity, expiration, and revocation lists. These checks again apply to any provider.
  • OpenStack Infrastructure: as an OpenStack-focused "related" project, we're going to include these as built-in plugins.

Contributed plugins

For example, cloud-specific plugins supporting providers like Rackspace or AWS. These will be included in the code base under a contrib module.

External plugins

These are plugins that are loaded as external module. Their source is not included in the satori repository. Example use cases might be a plugin that integrates into a proprietary CMDB database.


Plugin Loading Options

Default Run: All built-in and contrib plugins load by default.

Selected Plugins Only: One or more plugins can be singled out to run.

Select Plugins to Add to Default: One or more external plugins can be included to a default run.

These options are available as environment variables and CLI options.


CLI examples

Exploring different use cases:

I want to pip install, run and have it just work

Default command, no options specified, runs with all built-in and contrib plugins:

$ satori foo.com
I want to run satori with my proprietary plugins but I don't want to have to list them with every call I make

Default command, no options specified, runs with all built-in and contrib plugins (as well as any external plugins supplied as environment variables):

$ SATORI_PLUGINS=myco.plugins satori foo.com
I want to run satori with just one plugin for testing and/or experimentation

Use the --only argument with the name of the plugin:

$ satori --only dns foo.com  # no prefix required for internal plugins
$ satori --only mypackage.mymodule foo.com
I want to run satori and select which plugin to use for system information discovery (out of a few available ones)

Use the --use argument with the name of the plugin:

$ satori --use ohai foo.com
$ satori --use blueprint foo.com
I want to run satori and select a specific external plugin for this one run in addition to built-in and contrib plugins

Use the --include argument with the name of the plugin:

$ satori --include mypackage.mymodue foo.com