Hi Tirthankar, thank you for your explanations, they help to understand the ideas behind your solution. I think we have identified ways for improvement, but I don't see any show stoppers at the moment, as long as the solution will be tested for multiple partitioning scenarios.
There is one last point I'd like to add though: > The documented procedure > http://docs.sun.com/app/docs/doc/819-2971/z4000076997776?l=en&a=view > <http://docs.sun.com/app/docs/doc/819-2971/z4000076997776?l=en&a=view> > is to evacuate a node for maintenance. Unconfiguring it would be too > much of burden for the admin, IMHO. > > > Yes as the doc says > "Occasionally, when patching a node with a Sun Cluster patch, you might > need to temporarily remove a node from cluster membership or stop the > entire cluster before installing the patch." Agree, but IMHO, this means changing dynamic membership (iow booting a node do single user non-cluster (-sx), right?). And as your code changes the way dynamic membership is determined, you can only query for static membership to get the total cluster size, right? + // Calculate the number of nodes configured + // in the cluster. This is static membership + // + for (node = 1; node <= NODEID_MAX; node++) { + if (orb_conf::node_configured(node)) { + // Increment the number of nodes + num_nodes++; + } The disadvantage is that this way there is no information as to the maximum practical cluster size, all we know is the maximum theoretical cluster size. To change static membership by removing a node from the cluster is not very practical (see http://docs.sun.com/app/docs/doc/819-2971/6n57mi2en?l=en&a=view#gcfso ) so it might help to add for future ohac versions a property to temporarily exclude a node from static membership without unconfiguring it. Thanks, Nils
