Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
To: drbd-user at lists.linbit.com Lars Ellenberg wrote: On Mon, Nov 14,2016 at 10:12 >On Sat, Nov 12, 2016 at 09:45:39AM +0000, CART Andreas wrote: >> On Thu, Nov 10,2016 at 13:21 >> To: drbd-user at lists.linbit.com Lars Ellenberg wrote: >> > On Thu, Nov 10, 2016 at 12:05:09PM +0000, CART Andreas wrote: >> >> I again started with all resources located at ventsi-clst1 and >> >> issued a 'pcs resource move DRBD_global_clst' (the resource next >> >> collocated next to the DRBDClone). >> >> >> >> With that I end up with all primitive resources stopped and the >> >> DRBDClone resource still being master at ventsi-clst1. >> > >> > I don't think that has anything to do with DRBD, (you'll see that >> > when you try with some dummy resources instead). >> > >> > Just moving something "top of the dependency chain" won't move the >> > bottom of the dependency chain, especially not a Master role. >> > This is a Pacemaker shortcoming. >> >> I am pretty sure that's not generally true (although I'm new to DRBD >> and pacemaker and always willing to learn). > > Prepare a cib with dummy resources (ocf:pacemaker:Dummy, > ocf:pacemaker:Stateful), and add similar constraints, then start experimenting. > > If you find suboptimal behaviour, you have a nice little example you can > show upstream when filing bug fix or enhancement requests for how > pacemaker "should" deal with certain situations. > > If with dummy resources you find behaviour to significantly differ from > what you get with "real" resources, and the dummy setup behaves "better" > for your definition of better, you still have a nice > example to show how you "want" things to behave, and we can more easily > look into why things don't behave that way with "real" resources. I did not expect it to be a DRDB-bug but rather a configuration problem for a very common setup of a clustered NFS server on top of DRBD as it is documented in numerous writings. Hopefully someone familiar with this sort of setup would easily point out the obvious misconfiguration I did not see. Unfortunately no one here chimed in ... so I had to do it the hard way ... and can now conclude that it's no pacemaker bug or shortcoming either. It was simply a configuration problem (as expected). Anyone interested in the details might have a look at http://clusterlabs.org/pipermail/users/2016-November/004598.html Kind regards Andi