[ClusterLabs] Pacemaker not always selecting the right stonith device

[Klaus Wenninger]

On 07/21/2016 06:40 PM, Andrei Borzenkov wrote:
> 19.07.2016 18:24, Klaus Wenninger пишет:
>> On 07/19/2016 04:17 PM, Ken Gaillot wrote:
>>> On 07/19/2016 09:00 AM, Andrei Borzenkov wrote:
>>>> On Tue, Jul 19, 2016 at 4:52 PM, Ken Gaillot <kgaillot at redhat.com> wrote:
>>>> ...
>>>>>> primitive p_ston_pg1 stonith:external/ipmi \
>>>>>>  params hostname=pg1 ipaddr=10.148.128.35 userid=root
>>>>>> passwd="/var/vcap/data/packages/pacemaker/ra-tmp/stonith/PG1-ipmipass"
>>>>>> passwd_method=file interface=lan priv=OPERATOR
>>>>>>
>>>> ...
>>>>> These constraints prevent each device from running on its intended
>>>>> target, but they don't limit which nodes each device can fence. For
>>>>> that, each device needs a pcmk_host_list or pcmk_host_map entry, for
>>>>> example:
>>>>>
>>>>>    primitive p_ston_pg1 ... pcmk_host_map=pg1:pg1.ipmi.example.com
>>>>>
>>>>> Use pcmk_host_list if the fence device needs the node name as known to
>>>>> the cluster, and pcmk_host_map if you need to translate a node name to
>>>>> an address the device understands.
>>>>>
>>>> Is not pacemaker expected by default to query stonith agent instance
>>>> (sorry I do not know proper name for it) for a list of hosts it can
>>>> manage? And external/ipmi should return value of "hostname" patameter
>>>> here? So the question is why it does not work?
>>> You're right -- if not told otherwise, Pacemaker will query the device
>>> for the target list. In this case, the output of "stonith_admin -l"
>>> suggests it's not returning the desired information. I'm not familiar
>>> with the external agents, so I don't know why that would be. I
>>> mistakenly assumed it worked similarly to fence_ipmilan ...
>> guess it worked at the times when pacemaker did fencing via
>> cluster-glue-code...
>> A grep for "gethosts" doesn't return much for current pacemaker-sources
>> apart
>> from some leftovers in cts.
>
> Pacemaker is expected to call fence_legacy which translates "list" into
> "gethosts". It does it in my case. So it appears a problem of this
> specific installation.
As said in some other branch of this discussion I don't have an
installation with legacy-fencing here at the moment ... the final
translation to gethosts should be done by the test-binary coming
from cluster-glue ...
But I'm still a little surprised as fence_legacy doesn't mention
'list' in the actions-section of the meta-data it creates for the
legacy-agents.
Playing with fence_dummy it didn't go for the dynamic-list
anymore once I had removed the 'list' action from the
meta-data. Hence my suggestion to give it a try with
this action added. But I haven't checked in the code if there is
some special-handling for legacy-fencing from pacemaker-side.