[ClusterLabs] How to achieve next order behavior for start/stop action for failover

[Novik Arthur]

Hello community!
I'm not sure if pacemaker can do it or not with current logic (maybe it
could be a new feature), but it's worth asking before starting to "build my
own *Luna*-*park* ,with *blackjack* and ...."

*Right now* I have something like:
MGS -> MDT -> OST
order mdt-after-mgs* Optional*: mgs:start mdt:start
order ost-after-mgs *Optional*: mgs:start ost:start
order ost-after-mdt0000 *Optional*: mdt0000:start ost:start

   - We have 4 nodes (A,B,C,D).
   - Nodes A and B carry MGS.
   - Nodes A,B,C,D carry MDT000[0-3] - one per node.
   - Nodes A,B,C,D carry OST000[0-3] - one per node.
   - If we stop nodes A and B, MGS will be stopped since there is NO
   placement to start for it, but MDT000[0-1] and OST000[0-1] could failover
   and will try to do that and will fail since MGS is a mandatory for us (and
   by the end will be blocked), *but I use optional to avoid unnecessary
   stop/start chain for MDT/OST*.

*I want to avoid unnecessary STOP/START actions of each dependent resource
in case of failover, but preserve the order and enforce MGS dependency for
those resources which are stopped (so, to start I need to follow the chain
and if started then do nothing). Th**ink about it like separate procedures
for 1st start and failover during work... like soft-mandatory or something
like that.*

I think that if I tweak OCF start/stop (make them dummy and always success)
and move all logic to monitors with deep checks, so that monitor could
mount/umount and etc. + assign transient attrs which could track ready or
not for start, and create location rules which prefer/honor transient
attrs, then I could achieve desirable state, but it looks very complex and
probably doesn't worth it...

I would love to see any thoughts about it.

Thanks,
A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20231204/aea5a8fb/attachment.htm>