blob: 5552c05455aa03dd6d58b6678fa864a8cbc0b9d4 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
This documents available plugin roles.
1) list of plugin roles
| Role | Class | Status |
|---------------+--------------------+---------------|
| Metadata | Metadata | done |
| Connector | Connector | done |
| Probing | Probing | done |
| Structure | Structure | done |
| Structure Val | StructureValidator | done |
| Generator | Generator | done |
| Goals Val | GoalValidator | done |
| Statistics | Statistics | class defined |
| Pull | PullSource | done |
| Decision | Decision | done |
| Remote | Remote | none |
| Syncing | Syncing | none |
|---------------+--------------------+---------------|
2) Plugin Functions
* Metadata
** Initial metadata construction
** Connector data accumulation
** ClientMetadata instance delivery
** Introspection interface (for bcfg2-info & co)
* Connector
** Provide additional data for ClientMetadata instances
* Probing
* Structure
* Structure Validation
* Generator
* Goals Validation
* Pull
* Decision
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.
4) User Visible Changes
Connector data is added to ClientMetadata instances using the name of
the connector plugin. This means that the dictionary of key/val probe
pairs included with metadata is now available as metadata.Probes
(instead of metadata.probes). Once properties are available the same
way, they will likewise change names to metadata.Properties from their
current name.
5) Notes
* Need to fix host specific probe behavior (with basenames)
|
