Bug 218951 - Conga (luci) can display misleading information about state of node during cluster creation
Summary: Conga (luci) can display misleading information about state of node during cl...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: conga
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jim Parsons
QA Contact: Corey Marthaler
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-12-08 17:43 UTC by Len DiMaggio
Modified: 2009-04-16 22:33 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-12-11 15:09:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Errors in red and grey (328.78 KB, image/png)
2006-12-08 17:43 UTC, Len DiMaggio
no flags Details

Description Len DiMaggio 2006-12-08 17:43:21 UTC
Description of problem:
Conga (luci) can display misleading information about state of node during
cluster creation

Version-Release number of selected component (if applicable):
luci-0.8-25.el5

How reproducible:
Not very - I've seen this problem twice today - not sure of the cause yeteproduce:
1. Create a new cluster - if one of the nodes is unable to join the cluster due
to a cluster daemon not starting or being stopped, the cluster node will be
still be listed as green in the cluster display in luci
2. See the attachments for examples

Actual results:
The node is reported in green, not red or grey

Expected results:
I'd expect that if ricci is running, the erroring node would be listed in red.

Additional info:

I'd like to have a better understanding of the criteria by which nodes are
displayed in green, red, and grey by luci. 

See the first attachment:

   Node 1: DLM is unable to make a connection, and the node is displayed in green
   Node 3: ccsd is unable to connect, and the node is displayed in red

Comment 1 Len DiMaggio 2006-12-08 17:43:21 UTC
Created attachment 143175 [details]
Errors in red and grey

Comment 2 Ryan McCabe 2006-12-08 19:24:23 UTC
It looks like everything is as it should be -- only node 3 is down, and it's
displayed in red. The error messages displayed in the logs on node 1 indicate
that DLM cannot communicate with node 3, which is expected, because node 3 is
not a cluster member.

What does the clustat output look like on each of the nodes?

Comment 3 Len DiMaggio 2006-12-11 14:41:05 UTC
The nodes in question have since been rebooted - more than once - I'll try to
recreate the problem again today. Can you point me at a definition of what
causes the nodes' status to be: green, red, or grey? Thanks.

Comment 4 Ryan McCabe 2006-12-11 15:09:55 UTC
A node is displayed green if the node is a cluster member; red if it's not a
cluster member; and gray if its membership status is unknown, the node is down,
or is unreachable. I'm going to close this as not a bug. It looks like luci is
displaying the state of the cluster accurately in the screen shot you posted.
Nodes 1 and 4 are up, so should be green. 3 isn't a member, and it's red. The
error messages displayed at node 1 are regarding not being able to create a dlm
association on node 3, which is not a cluster member.

Please reopen if clustat output indicates the membership state of the cluster is
different from what luci is showing.

Comment 5 Len DiMaggio 2006-12-11 16:18:17 UTC
Thanks for the explanation Ryan - one more question - in this context, what does
it mean for a node to be "not a cluster member"?

If the node is displayed in the cluster's node list - then as far as luci is
concerned it's a member of the cluster, right?


Comment 6 Len DiMaggio 2006-12-11 16:20:07 UTC
In other words - what's the threshold that has to be crossed (which
services/daemons) must be stopped for a cluster node to go from red to grey?

Comment 7 Len DiMaggio 2006-12-11 18:09:18 UTC
Thanks for the information Ryan - if clustat reports the node is offline, but
the node is still up - then it's red. If the node is down, then it's grey.




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