fuel-dev team mailing list archive

[Andrey Korolyov <akorolev@xxxxxxxxxxxx>]

On 01/14/2014 01:59 PM, Aleksandr Didenko 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
> 
> 

Sounds great but will be complete mess during development stage. Can be
fixed via tgz archives during development window and 'equal' packages
during code freeze testing.

> 
> On Sat, Jan 4, 2014 at 8:38 PM, Sergey Vasilenko
> <svasilenko@xxxxxxxxxxxx <mailto: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
>     <mailto: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
>         <mailto: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
>     <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~fuel-dev
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
>