Hi, > But if A can tolerate outage of B, why does it matter whether A is started > before or > after B? By the same logic it should be able to reconnect once B is up? At > least that > is what I'd expect. In our case B is the file system resource that stores the configuration file for resource A. Resource A is a cloned resource that is started on both servers in our cluster. On the active node, A should read the config file from the shared file system. On the passive node it reads a default file. After that the config file is not read anymore and thus the shared filesystem can go down and up again without disturbing the other resource.
After moving the filesystem to the passive node for failover, the process updates itself by reading the configuration from the now new ini file. This requires that the shared filesystem is started on the node, but I don't want to restart the process for internal reasons. I could start the processes before the shared filesystem is started and then always re-sync. However this will confuse the users because they don't expect this to happen. In the end we probably will not go with cloned resources and just start them cleanly after the shared filesystem is started on a node. This is much simpler and will solve the ordering problems here. It should also be possible to put everything in a group as they are additionally co-located. Cheers, Jens _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
