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 <[email protected]> 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 <[email protected]> > 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 >> > <[email protected] <mailto:[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] >> > <mailto:[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] >> > <mailto:[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] >> > <mailto:[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 > -- Dmitry Borodaenko -- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
