[ClusterLabs] start vs promote drbd m/s colocation constraint

[Ken Gaillot]

On Tue, 2021-02-02 at 14:27 -0700, Brent Jensen wrote:
> I've been trying to get my DRBD cluster on Centos8 / Pacemaker 2 to
> work but have had issues with cluster not failing over (I get error
> messages like "Refusing to be Primary while peer is not outdated").
> This has been explained in other posts. In trying different things I
> changed my constraint from PROMOTE to START and things seem to be
> working:
> DOES NOT WORK (works in pacemaker <2)
> pcs constraint order PROMOTE drbd0-clone then start fs_drbd
> 
> SEEMS TO WORK
> pcs constraint order START drbd0-clone then start fs_drbd

It's definitely a different effect; the second constraint only ensures
that some instance of drbd0-clone has started before starting fs_drbd.
No instance needs to be in the master role before starting fs_drbd.

> Note: The colocation constraint seems to work even if it's:
> "pcs constraint colocation add fs_drbd with drbd0-clone INFINITY
> with-rsc-role=Master id=nfs_on_drbd"
> or just "pcs constraint colocation add fs_drbd with drbd0-clone"

Similarly, the second constraint says only that fs_drbd has to run
where *any* instance of drbd0-clone is running, regardless of whether
it's master or not.

> What's the correct way for constraints on M/S DRBD? It just feels
> wrong doing just "start" instead of "promote" like I've been 

I haven't used DRBD in a while, but I believe newer versions handle the
equivalent of promotion internally, rather than via the resource agent
and pacemaker. It could be that you simply don't need a promotable
clone, just a regular clone. I don't know how that would actually work,
but it's maybe something to investigate.

> doing       over the last 15 years. In pacemaker 2.x the master/slave
> resource changed to clone so this is new to me.

master/slave -> promotable clone was purely a terminology change, the
behavior is identical

> Any input is most helpful!
> Brent
-- 
Ken Gaillot <kgaillot at redhat.com>