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