+1 It's not quite "for free" though - probably we'll need to maintain repos... 1 per OpenStack release?
But, yes, great idea! Kind regards, -Paul Reiber Phone: (650)430-7926 Email: [email protected] Web: http://bit.ly/reiber On Tue, Jan 14, 2014 at 1:59 AM, Aleksandr Didenko <[email protected]> wrote: > 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 > -- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
