fuel-dev team mailing list archive

[Andrew Woodward <xarses@xxxxxxxxx>]

We need to address that a lot (if not all) of puppet "plugins" will be
pre-baked from upstream sources. For example nagios. A user will want to be
able to use that module, and even keep it up to date with the upstream, we
should never modify the module existing files.

Each plugin has to be implemented as a separate module. Init manifest
> withouta input parameters (init.pp) should be used as an entry point to
> each plugin.
>
No, a separate bridging file plugin_fuel_<module>.pp should be created.


> All parameters for plugin should be kept in astute.yaml
>
We need to fail if a required parameter is not provided.

Function which automatically loads each plugin (e.g. it should execute init
> manifest of each class with name mask "plugin_.*") is required.
>
This likely need to be a function of astute and even our core modules
should be loaded this way. modules included should be based from data in
astute.yaml.


> Staging system should be implemented. All plugins have to be executed in a
> separate stage (e.g. Stage['main'] -> stage {'plugins':} )
>
We can't assume that this is OK. we can encourage plugins to use a separate
phase, however this is not enforceable in all cases (everything must be
loaded this way). We should create a set of standard stages, and create pre
and post stages as-well this way a plugin can insert its self where
necessary. A plugin without a stage should run last. Which stage might be
operated by astute.yaml

example stages might include: init, pre-networking, networking,
post-networking ...
(actual stages are
https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/osnailyfacter/examples/site.pp#L14-21
 )


> Each puppet class which is used with library has to have the ability to be
> disabled from plugin
> This is necessary because plugins may require to disable some services.
> Alternatively this can be implemented by using resource collections (e.g.
> Service <| title == l3-agent|> { noop => true }) but we can't execute
> plugin in a separate stage in this case.
>
This is mostly addressed by loading all modules, including core components
the same way. If you dont wat a core module to run, you simply get astute
to not run it. Some modules might still need further tweaking to allow more
flexible overriding. If all modules load the same way, we should be able to
simply replace the parameter into it's plugin_fuel_<module> class by
calling it instead of allowing it to be defined with the defaults.

Andrew Woodward
Mirantis