On Thu, Dec 7, 2023 at 7:07 AM Novik Arthur <freish...@gmail.com> wrote: > > Thank you Reid! > "Mandatory" with "symmetrical=false" did exactly what I wanted. > > Sincerely yours, > A
Adding the list back to confirm this is resolved. Thanks for confirming and for correcting my typo! Glad it's working as desired. > > пн, 4 дек. 2023 г. в 22:51, Reid Wahl <nw...@redhat.com>: >> >> On Mon, Dec 4, 2023 at 8:48 AM Novik Arthur <freish...@gmail.com> wrote: >> > >> > 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). Think about it like separate procedures >> > for 1st start and failover during work... like soft-mandatory or something >> > like that. >> >> You might try adding "symmetric=false". That option means the >> constraints apply to start but not to stop. >> >> Otherwise, I'm struggling to understand the actual vs. desired >> behavior here. Perhaps some example outputs or logs would be helpful >> to illustrate it. >> >> All of these ordering constraints are optional. This means they're >> applied only when both actions would be scheduled. For example, if mgs >> and mdt are both scheduled to start, then mgs must start first; but if >> only mdt is scheduled to start, then it does not depend on mgs. >> >> Perhaps the fact that these are cloned resources is causing the >> ordering constraints to behave differently from expectation... I'm not >> sure. >> >> >> > 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... >> >> Sometimes for complex dependencies, it can be helpful to configure an >> ocf:pacemaker:attribute resource (which usually depends on other >> resources in turn). This resource agent sets a node attribute on the >> node where it's running. The attribute can be useful in rules as part >> of more complicated constraint schemes. >> >> > >> > I would love to see any thoughts about it. >> > >> > Thanks, >> > A >> > >> > _______________________________________________ >> > Manage your subscription: >> > https://lists.clusterlabs.org/mailman/listinfo/users >> > >> > ClusterLabs home: https://www.clusterlabs.org/ >> >> >> >> -- >> Regards, >> >> Reid Wahl (He/Him) >> Senior Software Engineer, Red Hat >> RHEL High Availability - Pacemaker >> -- Regards, Reid Wahl (He/Him) Senior Software Engineer, Red Hat RHEL High Availability - Pacemaker _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
