fuel-dev team mailing list archive

[Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx>]

Unless we move away from package based deployment altogether (which
btw I think would be a bad idea: I agree with Aleksandr and Ivan that
packages are more suitable for production), we have to make generation
of rpm and deb packages a part of our development process. I think the
best way to achieve that is have a public git-buildpackage repository
for each package we build, and use mr/myrepos to make rebuilding all
these packages a part of make iso, as an alternative to "make
deep_clean".

Having one deployment process for development and another process for
production is even worse than picking the wrong process. It would push
discovery of packaging-related bugs from the very beginning of the
development cycle (before the change is even pushed to gerrit) towards
the very end of the cycle (after a release candidate build was passed
to QA). It is widely accepted that the cost of fixing a bug grows
exponentially related to the time elapsed since the bug was
introduced.

My 2c,
-DmitryB


On Tue, Jan 14, 2014 at 1:13 PM, Ivan Kolodyazhny <e0ne@xxxxxxxxx> wrote:
> 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
>
>
>
> --
> 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
>



-- 
Dmitry Borodaenko