diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/1.0-roadmap | 10 | ||||
-rw-r--r-- | doc/plugin-roles | 34 |
2 files changed, 29 insertions, 15 deletions
diff --git a/doc/1.0-roadmap b/doc/1.0-roadmap index 2d90d6f66..dc2236879 100644 --- a/doc/1.0-roadmap +++ b/doc/1.0-roadmap @@ -1,12 +1,12 @@ This document details the major work needed before Bcfg2 is ready for -a 1.0 release. +a 1.0 release. The high-level goal for 1.0 is to fix long-standing +architecture warts and provide a reasonable internal API for the +server. * Goals for 1.0 ** Fix the POSIX path problem ** Build a comprehensive server plugin architecture -*** Metadata Connectors (done) -*** Multi-stats -*** Structure Verifier/Modifier -*** Configuration Validator/Modifier +*** see plugin-roles for details and implementation status ** Version Control Backend ** Clean up client/server statistics data format +** Multithreaded server (sync from Cobalt) 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. |