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
