Bug 339471
| Summary: | Impossible to remove a dead node from cman | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Tim Verhoeven <tim.verhoeven.be> |
| Component: | cman | Assignee: | Ryan O'Hara <rohara> |
| Status: | CLOSED DUPLICATE | QA Contact: | GFS Bugs <gfs-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.0 | CC: | cluster-maint, jparsons, rmccabe |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-12-14 16:56:21 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tim Verhoeven
2007-10-19 11:04:57 UTC
It seems to me that a failed node should not prevent ccs_tool from updating cluster.conf Could this be an issue with Conga? I've never seen this behavior before. Added one of the Conga developers to the BZ CC list to perhaps help answer this question. 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. IIRC there was a bug in ccsd prior to 5.1 (I think the fix went out as a z-stream update) that caused ccsd to report failure when it you attempted to propagate a new configuration and there was at least one node that was not a member or estranged. It also happened if you were using qdisk (it'd try to send the new conf to node 0). See bug #244867 for more info. I just checked the sources for 2.0.64-1.0.1.el5 and the fix for that bug is not in there. Upgrading to the latest cman package ought to fix this. I'm unable to recreate this bug by using command-line tools. I guess I am unsure what step #1 (aka removing a node from a running cluster) actually means. It seems that removing the node means actually removing it from the cluster.conf file. This seems to be the case since it is stated that 'ccs_tool lsnode' lists only the remaining nodes, and 'ccs_tool lsnode' parses the cluster.conf file directory. So the node must be removed from the cluster.conf file. Its unclear that the node in question is still a member of the cluster or not, so I tested both scenarios. Running 'ccs_tool update /etc/cluster/cluster.conf' worked for me every time. Specifically, when the node was removed from the cluster.conf and still in the cluster and also when the node was removed from the cluster.conf but also left the running cluster. Ah. Comment #4 seems to explain the problem. I was testing on a RHEL5.1 machine, which has the fix that Ryan referenced. I think the problem reported here has been fixed in 5.1. |