fuel-dev team mailing list archive

[Paul Reiber <reiber@xxxxxxxxx>]

+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: paul@xxxxxxxxxx
Web: http://bit.ly/reiber


On Tue, Jan 14, 2014 at 1:59 AM, Aleksandr Didenko
<adidenko@xxxxxxxxxxxx> 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 <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
>>
>
>
> --
> 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
>