[ale] Red Hat upgrades?

[Jim Kinney]

On Fri, Jul 1, 2011 at 10:28 AM, James Sumners <james.sumners at gmail.com>wrote:

>
> I disagree with the assertion that stability comes with the cost of
> doing a fresh install every release. I've been upgrading Debian
> release-to-release since Slink with not one single stability problem.
> Of course there is planning involved and things change drastically.
> But that's why the upgrade process includes notices and prompts with
> diff access. You still have to do your homework, but you don't have to
> pretend it's 1975.
>
> I have found the stability to be more related to the admin sanity than the
OS :-) If I have a known baseline that works BEFORE I transition my old
application, I know that after the transition the errors are because of the
application and not the underlying OS.

I have a system I upgraded from fedora release to fedora release. The only
bare install was when the system was brand new. What I learned from doing
that process is :

1. eventually config files MUST be changed to match the new reality of an
upgraded binary
2. all upgrades require _work_.
3. compared to the RHEL/CEntOS system I also ran, the rolling upgrades cost
me more time over the life of the machine in upgrade work than the similar
lifespan of a RHEL machine with a major upgrade (I did several RHEL5>RHEL5
transitions.).

Stability is not guaranteed with a fresh install on a major upgrade. What
does happen is a decrease in the number of variables the admin must consider
when any system change causes instability. Additionally, a new installation
affords a fallback option in the event of a failure event after the
migration. That is a stability issue not of application but of service.

Additionally, from a professional admin standpoint, I find it to be bad
practice to be upgrading a production system to a new set of libs. By
definition, a production system is not eligible for an upgrade. It is only
allowed security and bug fix patches. To perform an OS upgrade is to change
a production system into a test system which must then pass QA before
becoming. So from that standpoint, it doesn't matter if a particular OS
support rolling upgrades or not, the professional admin best practices are
to put new code on new system, test, QA, promote to production, verify again
and then roll old production machine to test status for the next cycle.
-- 
-- 
James P. Kinney III

As long as the general population is passive, apathetic, diverted to
consumerism or hatred of the vulnerable, then the powerful can do as they
please, and those who survive will be left to contemplate the outcome.
- *2011 Noam Chomsky

http://heretothereideas.blogspot.com/
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110701/24012c99/attachment-0001.html