[ClusterLabs] Q: constrain or delay "probes"?

[Reid Wahl]

On Fri, Mar 5, 2021 at 10:13 AM Ken Gaillot <kgaillot at redhat.com> wrote:

> On Fri, 2021-03-05 at 11:39 +0100, Ulrich Windl wrote:
> > Hi!
> >
> > I'm unsure what actually causes a problem I see (a resource was
> > "detected running" when it actually was not), but I'm sure some probe
> > started on cluster node start cannot provide a useful result until
> > some other resource has been started. AFAIK there is no way to make a
> > probe obey odering or colocation constraints, so the only work-around
> > seems to be a delay. However I'm unsure whether probes can actually
> > be delayed.
> >
> > Ideas?
>
> Ordered probes are a thorny problem that we've never been able to come
> up with a general solution for. We do order certain probes where we
> have enough information to know it's safe. The problem is that it is
> very easy to introduce ordering loops.
>
> I don't remember if there any workarounds.
>

Maybe as a workaround:
  - Add an ocf:pacemaker:attribute resource after-and-with rsc1
  - Then configure a location rule for rsc2 with resource-discovery=never
and score=-INFINITY with expression (in pseudocode) "attribute is not set
to active value"

I haven't tested but that might cause rsc2's probe to wait until rsc1 is
active.

And of course, use the usual constraints/rules to ensure rsc2's probe only
runs on rsc1's node.


> > Despite of that I wonder whether some probe/monitor returncode like
> > OCF_NOT_READY would make sense if the operation detects that it
> > cannot return a current status (so both "running" and "stopped" would
> > be as inadequate as "starting" and "stopping" would be (despite of
> > the fact that the latter two do not exist)).
>

This seems logically reasonable, independent of any implementation
complexity and considerations of what we would do with that return code.


> > Regards,
> > Ulrich
> --
> Ken Gaillot <kgaillot at redhat.com>
>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/
>
>

-- 
Regards,

Reid Wahl, RHCA
Senior Software Maintenance Engineer, Red Hat
CEE - Platform Support Delivery - ClusterHA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20210305/dd534775/attachment-0001.htm>