fuel-dev team mailing list archive

[Ivan Kolodyazhny <e0ne@xxxxxxxxx>]

RPMs is good for production use. For development process we need to specify
some workflow and create guidelines like a Nailgun docs to easy get
development environment.


--
Regards,
Ivan "e0ne" Kolodyazhny

On Tue, Jan 14, 2014 at 7:35 PM, Andrey Korolyov <akorolev@xxxxxxxxxxxx>wrote:

> 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
> >
> >
> >
> >
>
>
> --
> 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
>