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
Hi,
> >> shared_fs has to wait for the DRBD promotion, but the other resources
> >> have no such limitation, so they are free to start before shared_fs.
> > Isn't there an implicit limitation by the ordering constraint? I have
> > drbd_promote < shared_fs < snmpAgent-clone, and I would expect
deliver
this message to anyone else. In such case, you should destroy this message and
are asked to notify the sender by reply e-mail.
Von: Ken Gaillot [kgail...@redhat.com]
Gesendet: Mittwoch, 21. September 2016 16:30
An: users@clusterlabs.org
Betreff: Re: [Clu
§ 35a GmbHG / §§ 161, 125a HGB finden Sie unter
> de.cgi.com/pflichtangaben.
>
>
>
> Von: Auer, Jens [jens.a...@cgi.com]
> Gesendet: Mittwoch, 21. September 2016 15:10
> An: users@clusterlabs.org
> Betreff: [ClusterLabs] kin
emäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
de.cgi.com/pflichtangaben.
Von: Auer, Jens [jens.a...@cgi.com]
Gesendet: Mittwoch, 21. September 2016 15:10
An: users@clusterlabs.org
Betreff: [ClusterLabs] kind=Optional order constraint not wor
Hi,
in my cluster setup I have a couple of resources from which I need to start
some in specific order. Basically I have two cloned resources that should start
after mounting a DRBD filesystem on all nodes plus one resource that start
after the clone sets. It is important that this only
