Bug 457104 - improve upgrades to RHEL6
Summary: improve upgrades to RHEL6
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cman
Version: 5.2
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: David Teigland
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-29 16:46 UTC by David Teigland
Modified: 2009-04-16 23:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-20 21:53:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
groupd patch (4.74 KB, text/plain)
2008-08-21 22:09 UTC, David Teigland
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0189 0 normal SHIPPED_LIVE cman bug-fix and enhancement update 2009-01-20 16:05:55 UTC

Description David Teigland 2008-07-29 16:46:55 UTC
Description of problem:

Rolling upgrades from RHEL5 to RHEL6 will work better if we add code
to RHEL5 groupd that sends out a message advertising its version.
Without this, RHEL6 groupd assumes an old version after not receiving
a version message after a timeout period.  The timeout+assumption works
(and needs to for rolling upgrades of 5.1 or 5.2 to RHEL6), but is obviously
slower and less reliable than actually getting a message.  The sooner we
include this in RHEL5, the more likely that RHEL5->6 upgrades can take advantage
of this improvement.  These version messages will not affect the behavior of a
RHEL5-only cluster.

Another future problem we can mitage now, is the case where RHEL6 nodes form
a new cluster, and select the new incompatible groupd mode because no RHEL5
nodes are found (this "auto-detection" is the behavior we want).  Then, an
old RHEL5 node joins the cluster (people shouldn't do this, but it may happen).
 It would be nice to prevent the old RHEL5 groupd from doing
anything, because it won't be in sync with the RHEL6 nodes running in the
new mode.  The simplest way to do this is for the old groupd to look at the
version messages from the new RHEL6 nodes, and exit when it sees they are
incompatible.  Again, this will only affect the groupd behavior once there
are mixed RHEL5/RHEL6 nodes.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 RHEL Program Management 2008-07-29 17:00:43 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 2 David Teigland 2008-08-21 22:09:31 UTC
Created attachment 314758 [details]
groupd patch

Patch is attached.  Have now tested this on RHEL5 without problems.
There's not much to test, really, because the new code never does
anything; it just sends a new message that's ignored.  Most of the
new code is the standard setup for a new message type.

The RHEL6 version of groupd will actually use these new messages
being sent to "see" the RHEL5 nodes.

Comment 3 David Teigland 2008-08-26 16:44:53 UTC
pushed to RHEL5 and STABLE2 branches

Comment 6 errata-xmlrpc 2009-01-20 21:53:15 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0189.html


Note You need to log in before you can comment on or make changes to this bug.