On 01/13/2012 12:14 PM, David Teigland wrote: > 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 Actually, having the cache on each node with the intention of diff'ing them when divergent was part of what I had in mind. I have no interest or concern on how it's implemented, of course. I just see things from the admin and support side of things. So anything that gives me a node's view of the cluster in a relatively easy to read manner makes me happy. -- Digimer E-Mail: digimer@xxxxxxxxxxx Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "omg my singularity battery is dead again. stupid hawking radiation." - epitron _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
