[ale] Red Hat upgrades?

[Michael H. Warfield]

On Tue, 2011-07-05 at 17:29 -0400, The Don Lachlan wrote: 
> On Tue, Jul 05, 2011 at 04:19:36PM -0400, Michael H. Warfield wrote:
> > 2) You can run at least 13 months.  The Fedora edition is not EOL'ed
> > until the initial test versions of the +2 edition are posted.  F15 is

> 13 months is a pretty short window to me. If you're staying one revision
> back, it means that upgrading to N-1 on the day N is released gets you at
> most 7 months of production time and every 6 months you're running new
> versions of the OS through the SLC.

> That works for you - great. It's not going to work for a lot of other
> people, myself included.

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
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110705/fb20ed84/attachment.bin