fuel-dev team mailing list archive

[Sergey Vasilenko <svasilenko@xxxxxxxxxxxx>]

I think we shouldn't tell about plugable architecture for fuel, before
divide one global manifest to set of small. First step (master-less)
already done.


On Fri, Jan 3, 2014 at 12:00 AM, Andrew Woodward <xarses@xxxxxxxxx> wrote:

> 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
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>