Bug 457104

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: