[DRBD-user] Can't Get DRBD Master/Slave out of secondary/secondary using pacemaker

Arnold Krille arnold at arnoldarts.de
Fri Oct 7 09:41:32 CEST 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Gotta revive this old thread...

On Friday 23 September 2011 22:28:30 Florian Haas wrote:
> On 2011-09-23 22:24, Arnold Krille wrote:
> > On Friday 23 September 2011 21:23:55 Florian Haas wrote:
> >> On 2011-09-23 19:06, Arnold Krille wrote:
> >>> On Friday 23 September 2011 17:54:26 Florian Haas wrote:
> >>> As far as I understand both the docs and my practical experience, the
> >>> order of elements in the colocation is irrelevant.
> >> Not trying to challenge your experience or your understanding of the
> >> documentation, but the idea that colocation constraints are
> >> non-directional is simply a wrong assumption.
> >> http://www.clusterlabs.org/mwiki/images/6/61/Colocation_Explained.pdf
> >> Slide 2.
> > Challenge accepted:) I will check my experience next week, the cluster
> > concerned isn't yet in productional use.
> Swap them around and stop or fail resources. Then it becomes evident
> fairly quickly.

I did create two Email-agents and one delay (with 60seconds start- and stop-
delay) in stopped state. I added one rule "colocation bla inf: Email1 Delay 
Email2", committed this, then I deleted the target-roles of these services to 
have them started upon commit. Guess what: The emails where sent immediately 
while the delay took its time. So I will go on spreading my interpretation of 
docs and experience: The order on a colocation doesn't matter.

Have fun,

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20111007/78a08f7a/attachment.pgp>


More information about the drbd-user mailing list