[ale] Red Hat upgrades?

Tue Jul 5 19:04:04 EDT 2011

On Tue, 2011-07-05 at 18:50 -0400, The Don Lachlan wrote: 
> Mike,
> 
> Really? Really?
> 
> Maybe you missed my statement of, "That works for you - great."
> 
> Who's doing all the QA work to verify applications work across versions?
> Who's checking that updates within a release of Fedora don't break things?
> Who's taking servers out of rotation every six months to upgrade them?
> 
> I'm glad you're lazy, but I don't have that kind of time EVERY SIX MONTHS.
> Lots of people don't have that time EVERY SIX MONTHS.

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

You're right.  It works for me.  And I have less time than you.  Far VAR
less time, I don't know or care how much time you have.  You have the
time to do this the other way.  That works for you - great.  That takes
me a lot more time to accomplish a lot less even with my level of
experience.  To each his own.  You very well may do better than me at
that and worse that me at this.  I accept that.  But to have anyone
question why I use Fedora on a production system is absolutely foolish.
I use it because it has worked for me for years.  Your mileage may vary.

> -L

Regards,
Mike 

> On Tue, Jul 05, 2011 at 06:12:58PM -0400, Michael H. Warfield wrote:
> > 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!
> 
> 
> 
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
> 

-- 
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/6dc08310/attachment.bin 