> On Jan 2, 2015, at 4:52 PM, Warren Young <w...@etr-usa.com> wrote: > > I’m not interested in the reverse case, where an old server could not take > over from a newer one, because there’s no good reason to manage the upgrade > that way. You drop the new one in as a backup, take the old one offline, > upgrade it, and start it back up, whereupon it can take over as primary again.
Most professional upgrades require a written and tested roll-back plan — and a published set of criteria (usually down-time) where the roll-back out of the failed “upgrade” MUST occur. Just sayin’… that’s a professional upgrade. What you described left out a lot of steps. An upgrade where the admin is “not interested” in going backward, is not what most of our employers will allow these days. Most of the ways to manage that on most OS’s without utilizing virtual machines, or entire filesystem snapshots… is truly awful if you try to do without either of those. The package managers sure aren’t written for it. It’s virtually impossible to find package management systems that can handle a properly done professional upgrade/test/revert cycle on any OS… (well, not without buying them, anyway… and they’re still slim pickin’s on *nix.) The other area most OS package managers suck badly is in creating IDENTICAL systems. It takes a LOT of sysadmin work and coddling of the package management tools currently en vogue, to make them do what businesses really want: e.g. If the QA machine has these exact 1000 packages installed on it, by god, that’s what I want on the Pre-Production server, and later on the Production server when they eventually get updates. I don’t want “yum update” grabbing whatever’s current, on those three different dates. Most of us are leveraging things like Ansible and Puppet to force such things… Things a good package management system would know how to do… since every business I’ve ever worked at needs both the ability to roll back, and the ability to make identical systems/package sets. Ah well, rant off… — Nate _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
