[ale] Red Hat upgrades?

James Sumners james.sumners at gmail.com
Tue Jul 5 18:45:27 EDT 2011


On Tue, Jul 5, 2011 at 6:12 PM, Michael H. Warfield <mhw at wittsend.com> wrote:
> Now mind you, I work with (not for) an IT department for a major
> international company that have taken that attitude at times that left
> them sitting on Solaris 8, in some cases, for ages because the upgrades
> are so painful (switching from Solaris to RHEL was less painful than
> Solaris 8 to Solaris 10).  RHEL 5 to RHEL 6 takes hours of downtime and
> adapting.  I did it in my VM's from CentOS 4 to CentOS 5.  You know what
> the "upgrade" path is?  You provision an entirely new VM and build it
> and migrate your data.  And it takes hours of work for one machine...
> Man!  Virtualization makes that work sooo much easier, and yet...  Net
> time, an upgrade from RHEL 4 to RHEL 5 for a major data center can take
> weeks and involve a lot of people depending on the number of servers.
> Slowlaris -- forget it.  Solaris 11 and ZFS has the right idea.  They
> can do live backup snapshots and upgrades and they can roll forward and
> backward.  We're not quite there yet.  Getting closer...  I don't say
> these things because I have not experienced them.  I have been there and
> done that.  I'm sorry.  I'm just too bloody lazy to work that hard.
>
> Now, lets see...  Every six to 12 months upgrading...  Oh, interesting,
> I can type (cut-n-paste) 6 commands into 30 or 40 windows one right
> after the other remotely turning them loose in maybe 15 minutes if I'm
> really slow.  Oh, wow.  I use a package cacher (pkg-cacher) so it only
> downloads the big stuff once.  Oh wow...  30 servers are done in under
> an hour (after the first one) and not a single error and the down time
> for them is less that 5 minutes each?
>
> Really?
>
> Really.
>
> Yes there can be gotcha's, particularly if you are a Postgresql fanatic
> like I am.  If I do a version upgrade I do need to backup and dump the
> databases and restore.  Oh well...  You learn and you do and you SCRIPT.
> Yes, it helps if you keep your servers in coherence and they have the
> same set of rpms (I try - Fedora is easier there too).  Yes, you
> sometimes have to resolve some conflicts but then you have this dump of
> your databases and you can cut-n-paste the uninstalls between all the
> machines just as fast.  I can do 30 machines using yum and have them all
> up in running in less than the down time of a RHEL single server upgrade
> when they go to to a "major upgrade".
>
> I can live with that every 6 to 12 months.  And I laugh my ass off at my
> IT people that complain that the server is going to be down for 12 hours
> for an upgrade (just because they can not predict what's going to break
> or how long it will take to fix it)...
>
> You guys work too hard and I'm a lazy bastard with better things to do.
> Fedora works for me.
>
>> -L
>
> Regards,
> Mike

I'm glad someone with a bigger resume than me gets it. All of this "no
upgrades between major versions means stability" garbage is merely a
justification for accepting a broken system (in my opinion). Like you,
I don't enjoy wasting hours of my time rebuilding ONE system and then
doing the same for the other X number of systems.

I just wish companies that say they "support Linux" didn't really mean
they "support Red Hat."

You mentioned that Fedora has gained the equivalent of `apt-get
dist-upgrade`. Does it also have the equivalent of `echo "postgresql
hold" | dpkg --set-selections` [1]? That would certainly help in your
upgrades when you know a package is going to require extra work.

[1] -- http://www.debianadmin.com/how-to-prevent-a-package-from-being-updated-in-debian.html


-- 
James Sumners
http://james.roomfullofmirrors.com/

"All governments suffer a recurring problem: Power attracts
pathological personalities. It is not that power corrupts but that it
is magnetic to the corruptible. Such people have a tendency to become
drunk on violence, a condition to which they are quickly addicted."

Missionaria Protectiva, Text QIV (decto)
CH:D 59



More information about the Ale mailing list