[Pacemaker] a question on the `ping` RA

[Andrew Beekhof]

On 10 Jun 2014, at 7:52 pm, Riccardo Murri <riccardo.murri at gmail.com> wrote:

> Hi Andrew, all,
> 
> sorry for this late reply -- currently I am only able to work on this
> issue very "part-time-ly"...
> 
> On 2 June 2014 13:34, Andrew Beekhof <andrew at beekhof.net> wrote:
>> 
>> On 2 Jun 2014, at 7:05 pm, Riccardo Murri <riccardo.murri at gmail.com> wrote:
>> 
>>> On 30 May 2014 02:38, Andrew Beekhof <andrew at beekhof.net> wrote:
>>>> 
>>>> On 29 May 2014, at 9:19 pm, Riccardo Murri <riccardo.murri at gmail.com> wrote:
>>>> 
>>>>> - or rather does the `ping` RA trigger failure events when even one of
>>>>> the nodes cannot be pinged?
>>>> 
>>>> both.  it always triggers events when something changes and its up
>>>> to the policy engine to look at your constraints and decide if
>>>> things should be moved.
>>> 
>>> Would the following be the correct configuration snippet to have
>>> pacemaker ignore occasional ping failures and only react when *no*
>>> hosts can be pinged?
>>> 
>>>   primitive ping ocf:pacemaker:ping \
>>>       params name=ping dampen=5s multiplier=10 host_list="..." \
>>>       op start timeout=120 \
>>>       op monitor timeout=60 interval=10 on-fail=ignore
>>>                                         ^^^^^^^^^^^^^^
>> 
>> Not really.  monitor failures are different from "i could only reach N out of M hosts"
>> The rule below is the correct part, but we'll still poke the PE to be sure everything is ok.
>>> 
>>>   clone ping_clone ping \
>>>       meta globally-unique=false clone-node-max=1
>>> 
>>>   [...]
>>> 
>>>   location mgt-location mgt \
>>>     rule -INFINITY: not_defined ping or ping number:lte 0
>>> 
> 
> Concerning "monitor failures are different": we have only seen a
> migration to happen as a result of a `ping_monitor_XXX` failure.  Does
> it trigger the `rule -INF: not_defined ping` part in the PE?

yes. if you want it to move to the most connected host, you'd want something like example 9.5 on:

    http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/_tell_pacemaker_how_to_interpret_the_connectivity_data.html

>  (The
> rules above are the rules we run in actual pacemaker setup, minus the
> `on-fail=ignore` which we do not have yet.)
> 
> Concerning "we'll still poke the PE to be sure everything is ok."
> Does this mean that every change in the ping score triggers a check on
> part of the PE?

yes

>  And the relevant rules would be those that evaluate
> `ping number`?

yes

> 
> Thanks,
> Riccardo
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140627/5ea3f254/attachment-0004.sig>