diff options
author | Narayan Desai <desai@mcs.anl.gov> | 2009-01-10 15:19:13 +0000 |
---|---|---|
committer | Narayan Desai <desai@mcs.anl.gov> | 2009-01-10 15:19:13 +0000 |
commit | d2bd788bdbe51463f82fda61d32d822e8c7a396e (patch) | |
tree | f88d6f172be36515f1cb3fe9917e9debb1182153 /doc/plugin-roles | |
parent | d922822bbe23387577e9e8c9f60131ac00a24c9f (diff) | |
download | bcfg2-d2bd788bdbe51463f82fda61d32d822e8c7a396e.tar.gz bcfg2-d2bd788bdbe51463f82fda61d32d822e8c7a396e.tar.bz2 bcfg2-d2bd788bdbe51463f82fda61d32d822e8c7a396e.zip |
More Plugin rework (Structure Validator implementation complete)
git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@5007 ce84e21b-d406-0410-9b95-82705330c041
Diffstat (limited to 'doc/plugin-roles')
-rw-r--r-- | doc/plugin-roles | 34 |
1 files changed, 24 insertions, 10 deletions
diff --git a/doc/plugin-roles b/doc/plugin-roles index d34a88c77..5d072dcbd 100644 --- a/doc/plugin-roles +++ b/doc/plugin-roles @@ -18,13 +18,27 @@ This documents available plugin roles. | Syncing | Syncing | none | |---------------+--------------------+---------------| - -2) Configuration of plugins - -3) Implementation Plan - -* Switch Plugin.__name__ => Plugin.name (Fix spurious pylint errors) [done] -* Switch all plugins to new class hierarchy [done] -* Fix Core to use memberships in new classes - - +2) Interactions between plugins and the core +* Metadata Construction +** Get Base Metadata from (single) Metadata plugin instance +** Get additional data from each Connector plugin instance +** Merge in additional connector data into single ClientMetadata instance +* + +3) Configuration of plugins + +Plugin configuration will be simplified substantially. Now, a single +list of plugins (including plugins of all capabilities) is specified +upon startup (either via bcfg2.conf or equivalent). This mechanism +replaces the current split configuration mechanism where generators, +structures, and other plugins are listed independently. Instead, all +plugins included in the startup list will be initialized, and each +will be enabled in all roles that it supports. This will remove a +current source of confusion and potential configuration errors, +wherein a plugin is enabled for an improper set of goals. (ie Cfg +enabled as a structure, etc) This does remove the possibility of +partially enabling a plugin for one of its roles without activating it +across the board, but I think this is a corner case, which will be +poorly supported by plugin implementers. If needed, this use case can +be explicitly supported by the plugin author, through use of a config +file directive. |