On Wed, 4 Nov 2009 15:33:19 +1000 Peter Tiggerdine wrote: > 7. Your going to need to copy this over manually otherwise it > will fail, I've fallen victim of this before. All cluster nodes need to start > on > the current revision of the file before you update it. I think this is a > chicken > and egg problem.
In the past I already encountered this situation. And in all cases, the starting node detects its version as not up2date and gets its new config from the other node. My scenario was: node 1 and node 2 up node 2 shutdown change node1 config (I mean here in term of services, probably not valid if inserting a qdiskd section when not available before, or possibly in other cases) power on node2 node 2 gets the new config and apply it (based on availability and correctness of definitions) So I don't think this is correct..... Any one commenting on this? Do you have the messages of the errors when you get this problem? On Wed, 4 Nov 2009 12:30:57 +0100 Jakov Sosic wrote: > Well I usually do rolling updates, (i relocate the services to other > nodes, and update one node, then restart it and see if it joins > cluster). OK. In fact I'm now working on a test cluster, just to get the correct workflow. But you are saying you did this also for 5.3 -> 5.4, while I experienced the oom problem that David documented too, with the entry in bugzilla...... So you joined a just updated 5.4 node to its previous cluster (composed by all 5.3 nodes) and you didn't get any problem at all? Gianluca
-- Linux-cluster mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-cluster
