On Fri, Jan 13, 2012 at 11:59:54AM -0500, David Teigland wrote: > On Fri, Jan 13, 2012 at 11:50:01AM -0500, Digimer wrote: > > On 01/13/2012 10:37 AM, David Teigland wrote: > > > Has the list of nodes specifically in cluster.conf been a source of > > > mistakes and support calls over the years? My belief is that a lack of a > > > node list would make the cluster more *difficult* to manage, not easier, > > > which is mainly why I think it should be there. As I said before, where > > > do you look for a list of all the nodes that *should* be in your cluster > > > when you think there might be one or two missing? On your whiteboard? > > > > What is the cluster used something akin to LVM or DHCP's method of > > caching information? Not a cache that has to be used for anything inside > > the cluster itself... simply something like; > > > > Node X joined with hash Y > > Node A joined with hash Y > > Node T joined with hash X > > > > This would provide support people with a reference for what nodes > > existed at some point in the past, and which nodes used a common (if > > any) passphrase, while not actually getting in the way of quorum without > > a user-set cluster list? > > The best thing that could be done for debugging IMO is including the > ringid in the membership log entries. And more to your point, it would be very useful to have a script or something create an easily readable summary of the cluster history. It would be most useful if it grabbed the logs/history from all nodes and gave a consolodated view. (When nodes have divergent views of the history is when this script would be most useful, so it should have a way of showing divergence of membership when it happens.) e.g. ring A,1 members a b c d ring A,2 members a b d then say a b are partitioned from d: X ring A,3 members a b X ring D,3 members d then they are merged: ring A,4 members a b d _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
