On Thu, Dec 10, 2009 at 9:59 AM, Steve Loughran <ste...@apache.org> wrote: > Edward Capriolo wrote: > system to ignore this file. >> >> So now that I am done complaining, what do I think should do? >> >> 1 clearly document your install process >> 2 make you install process fully script-table >> --or-- >> 3 role your own rpms (or debs, tar etc) for everything not in someone else >> RPM >> 4 run 1 nightly backup for the each server class >> 5 revision your config files >> 6 (optionally) use tripwires/MD5s only to check for unauthorized changes >> >> Anyway, my long short point, get something that works the way you want >> it to. Look out for systems that offer you "new" and "exciting" ways >> to do things that only take 10 seconds, like edit /etc/fstab, or >> install an RPM. > > RPMs are not actually that bad for getting stuff out, especially if you can > do PXE/kickstart stuff and bring up machines from scratch. One problem: the > need to rebuild and push out RPMs for every change, if you push out > configuration that way. > Other problems: > * its possible for different RPMs to claim ownership of things, much > confusion arises > * the RPM dependency model doesn't work that well with Java. I say that as > someone who has outstanding disputes with the JPackage scheme, and who also > knows that the maven/ivy dependency model is flawed too (how do you declare > in any of these tools that you want "an xml parser with XSD validation" > without saying which one. > * spec files are painful to work with, so is their build and test process. > You do have a test process, right ? > * The way RPMs upgrade is brain dead; they install the new stuff then decide > whether or not to uninstall the old stuff, makes it very hard to do some > upgrades that change directory structure > > -Steve > >
Let me kick it off with not everything fits every environment, your millage may vary. > RPMs are not actually that bad for getting stuff out, especially if you can > do PXE/kickstart stuff and bring up machines from scratch. One problem: the > need to rebuild and push out RPMs for every change, if you push out > configuration that way. True, you have to make the choice if you want to role your own RPM for your configuration files, or manage those on the side. Making an RPM called our-hadoop-config.rpm is actually not complicated compared to say learning how some other configuration pushing system works, and might take less time. > * its possible for different RPMs to claim ownership of things, much > confusion arises True again. I typically snapshot an RPM repo at a point in time. Then set it up as a local repository. The reason for this is change management. Running 'yum install hadoop' one day may not produce the exact same results the second day if you are using live internet repos. Using a list of repo's from the internet works well (sometimes conflicts) but not what you want in the end. >> * the RPM dependency model doesn't work that well with Java. I say that as Yes the RPM dependency model is poor for java. But the dependency model an administrator has to create for using say "CFEngine" is likely less well thought out, and probably just as frail and makes worse assumptions. Let me be clear, I am not advocating you add hundreds of RPM repositories to your /etc/yum.d directory and run 'yum install hadoop' and pray you get what you need consistently. I am saying you probably want to spend some time creating your own RPM repo and learning how to role your own packages that do exactly what you need. > * spec files are painful to work with, so is their build and test process. > You do have a test process, right ? True. But I look at the RPM for the finished product install to manage production systems. A good source rpm will run 'make test' on the package. I do not think a tool like rpm, puppet, or cfengine makes your built and test process any easier. It is a little out of scope. > * The way RPMs upgrade is brain dead; they install the new stuff then decide > whether or not to uninstall the old stuff, makes it very hard to do some > upgrades that change directory structure Out of a box a tool like puppet, cfengine, or the horrible tool I am force to use does not have any built-in intelligence for dealing with this (that I know of). An RPM the upgrade is only as smart as the pre-and post scripts the developer writes. Again, I am not saying , go get RPM X from site Y, you want to run your own repo (or possibly 1 repo per cluster) and role some of your own RPMs., so they do what you want.
