Bug 886632

Summary:	Fetch new cluster.conf on node startup
Product:	Red Hat Enterprise Linux 6	Reporter:	Jaroslav Kortus <jkortus>
Component:	cluster	Assignee:	Fabio Massimo Di Nitto <fdinitto>
Status:	CLOSED NOTABUG	QA Contact:	Cluster QE <mspqa-list>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.4	CC:	ccaulfie, cluster-maint, lhh, rpeterso, teigland
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-12 18:14:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jaroslav Kortus 2012-12-12 17:34:12 UTC

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:

Comment 2 Fabio Massimo Di Nitto 2012-12-12 18:14:10 UTC

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.

Comment 3 Jaroslav Kortus 2012-12-13 14:17:23 UTC

Thanks for the explanation :)