<br><font size=2 face="sans-serif">Well, in my case that was fairly easy.
 We have hardware mirrored system disks (/, /usr, /var, /root, /opt.....)
so prior to performing my upgrades, I migrated any services that were running
on that node, quiesced the system and then broke the mirror.   I then
brought the system back up with all the cluster services switched off,
performed the upgrade and in each case the node then re-joined the cluster
without a problem.  </font>
<br>
<br><font size=2 face="sans-serif">I'm not familiar with version control
that you can perform with "Wayback" but the principal would be
the same, ie, keeping a known good OS version that you could fall back
to in case of a problem.</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>gordan@bobich.net</b> </font>
<br><font size=1 face="sans-serif">Sent by: linux-cluster-bounces@redhat.com</font>
<p><font size=1 face="sans-serif">01/11/2008 11:37 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
linux clustering <linux-cluster@redhat.com></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">linux clustering <linux-cluster@redhat.com></font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: [Linux-cluster] RHEL
4.5 -> 4.6 migration</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>I'm curious - please, do tell about the solid rollback
plan. Something <br>
like the stackable wayback file system for root?<br>
<br>
On Fri, 11 Jan 2008, Paul n McDowell wrote:<br>
<br>
> I did a rolling upgrade of a 5 node GFS environment from 4.5 to 4.6
over a<br>
> week and had no interoperability issues.  I made sure that I
had a solid<br>
> roll-back plan before I upgraded each node just in case.<br>
><br>
><br>
><br>
><br>
><br>
> rhurst@bidmc.harvard.edu<br>
> Sent by: linux-cluster-bounces@redhat.com<br>
> 01/11/2008 10:36 AM<br>
> Please respond to<br>
> linux clustering <linux-cluster@redhat.com><br>
><br>
><br>
> To<br>
> linux-cluster@redhat.com<br>
> cc<br>
><br>
> Subject<br>
> [Linux-cluster] RHEL 4.5 -> 4.6 migration<br>
><br>
><br>
><br>
><br>
><br>
><br>
> Has anyone migrated from an existing 4.5 to the newer 4.6 cluster
suite?<br>
> We would like to roll out 4.6 in our 11-node cluster, but only one
node at<br>
> a time, over the course of 2-weeks.  Does the two versions intermix
well<br>
> enough to do that?   Or do we need to do take some kind of special
care or<br>
> precaution, like when injecting this dilithium crystal chamber with
an<br>
> inverse tachyon pulse from the main deflector dish?<br>
> --<br>
> Linux-cluster mailing list<br>
> Linux-cluster@redhat.com<br>
> https://www.redhat.com/mailman/listinfo/linux-cluster<br>
><br>
<br>
--<br>
Linux-cluster mailing list<br>
Linux-cluster@redhat.com<br>
https://www.redhat.com/mailman/listinfo/linux-cluster<br>
</font></tt>
<br>