[ClusterLabs] kind=Optional order constraint not working at startup

[Auer, Jens]

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