On Wed, 4 Nov 2009 15:33:19 +1000 Peter Tiggerdine wrote:OK. In fact I'm now working on a test cluster, just to get the correct workflow.
> 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).
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 Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
