fuel-dev team mailing list archive

[Aleksandr Didenko <adidenko@xxxxxxxxxxxx>]

One more thing to consider: plugins packaging into RPMs. This will provide
a set of benefits "for free", for example:

- versioning
- easy installation/removal/upgrades/downgrades/distribution
- dependencies (including cross plugin dependencies)
- conflicts (including cross plugin conflicts)
- plugin consistency check (rpm -qV)

Thanks
--
Aleksandr



On Sat, Jan 4, 2014 at 8:38 PM, Sergey Vasilenko <svasilenko@xxxxxxxxxxxx>wrote:

> 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
>>
>>
>
> --
> 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
>
>