Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
RHCS in RHEL6 has no longer the ability to automatically download new cluster.conf.

If a node goes offline (including ricci), then the other nodes process an update of the configuration, and then the first node rejoins, it does not get the cluster.conf. It will just complain and service cman start will fail.

It would be good to have the ability back, as it was present in RHEL5 times.

How reproducible:
always

Steps to Reproduce:
1. form a cluster
2. leave with one node, shutdown ricci
3. update configuration on other nodes
4. rejoin node from (2) via service cman start
  
Actual results:
node does not rejoin

Expected results:
fresh config fetched from one of the remaining nodes
node rejoins successfully with new config

Additional info:

This is by design. ricci does not support "pull" and doesn´t start early enough before cman. cman has no configuration management internally to distribute a configuration.

If anything, ricci would have to do the work before cman.

cman refusing to start is a sanity check to avoid joining a cluster with config options that might not be changeable at runtime.

For example:

cluster has version 2 with a new token.timeout.

node rejoins with version 1 with older token.timeout.

token.timeout cannot be reconfigured at runtime. Hence, even if cman could pull the config, it would not work in that cluster as expected, creating more troubles than it solves.

Also, for RHEL6 we used a different approach than RHEL5.

See what every other daemon do. If the config is not right, don´t start. The possibility we had to pull the new on in RHEL5 is badly designed, it allows the above situation to form a cluster and sets wrong expectations.

Thanks for the explanation :)