[ClusterLabs] pcs stonith update <id> <args> problems

[Tomas Jelinek]

Dne 21. 07. 21 v 19:06 Digimer napsal(a):
> On 2021-07-21 8:19 a.m., Tomas Jelinek wrote:
>> Dne 16. 07. 21 v 16:30 Digimer napsal(a):
>>> On 2021-07-16 9:26 a.m., Tomas Jelinek wrote:
>>>> Dne 16. 07. 21 v 6:35 Andrei Borzenkov napsal(a):
>>>>> On 16.07.2021 01:02, Digimer wrote:
>>>>>> Hi all,
>>>>>>
>>>>>>      I've got a predicament... I want to update a stonith resource to
>>>>>> remove an argument. Specifically, when resource move nodes, I want to
>>>>>> change the stonith delay to favour the new host. This involves adding
>>>>>> the 'delay="x"' argument to one stonith resource, and removing it from
>>>>>> the other;
>>>>>>
>>>>>> Example;
>>>>>>
>>>>>> ====
>>>>>> # pcs cluster cib | grep -B7 -A7 '"delay"'
>>>>>>          <primitive class="stonith" id="ipmilan_node1"
>>>>>> type="fence_ipmilan">
>>>>>>            <instance_attributes id="ipmilan_node1-instance_attributes">
>>>>>>              <nvpair id="ipmilan_node1-instance_attributes-ipaddr"
>>>>>> name="ipaddr" value="10.201.17.1"/>
>>>>>>              <nvpair id="ipmilan_node1-instance_attributes-password"
>>>>>> name="password" value="xxx"/>
>>>>>>              <nvpair
>>>>>> id="ipmilan_node1-instance_attributes-pcmk_host_list"
>>>>>> name="pcmk_host_list" value="an-a02n01"/>
>>>>>>              <nvpair id="ipmilan_node1-instance_attributes-username"
>>>>>> name="username" value="admin"/>
>>>>>>              <nvpair id="ipmilan_node1-instance_attributes-delay"
>>>>>> name="delay" value="15"/>
>>>>>>            </instance_attributes>
>>>>>>            <operations>
>>>>>>              <op id="ipmilan_node1-monitor-interval-60" interval="60"
>>>>>> name="monitor"/>
>>>>>>            </operations>
>>>>>>          </primitive>
>>>>>> ====
>>>>>>
>>>>>> Here, the stonith resource 'ipmilan_node1' has the delay="15".
>>>>>>
>>>>>> If I run:
>>>>>>
>>>>>> ====
>>>>>> # pcs stonith update ipmilan_node1 fence_ipmilan ipaddr="10.201.17.1"
>>>>>> password="xxx" username="admin"; echo $?
>>>>>> 0
>>>>>> ====
>>>>>>
>>>>>> I see nothing happen in journald, and the delay argument remains in
>>>>>> the
>>>>>> 'pcs cluster cib' output. If, however, I do;
>>>>>>
>>>>>> ====
>>>>>> # /usr/sbin/pcs stonith update ipmilan_node1 fence_ipmilan
>>>>>> ipaddr="10.201.17.1" password="xxx" username="admin" delay="0";
>>>>>> echo $?
>>>>>> 0
>>>>>> ====
>>>>>>
>>>>>> I can see in journald that the CIB was updated and can confirm in 'pcs
>>>>>> cluster cib' that the 'delay' value becomes '0'. So it seems that,
>>>>>> if an
>>>>>> argument previously existed and is NOT specified in an update, it
>>>>>> is not
>>>>>> removed.
>>>>>>
>>>>>> Is this intentional for some reason? If so, how would I remove the
>>>>>> delay
>>>>>> attribute?
>>>>
>>>> Yes, this is intentional. As far as I remember, update commands in pcs
>>>> have always worked this way:
>>>> * do not change attributes not specified in the command
>>>> * if an attribute is specified with an empty value, remove the attribute
>>>> from cluster configuration
>>>> * else set specified value of the specified attribute in cluster
>>>> configuration
>>>>
>>>> This means you only need to specify attributes you want to change. You
>>>> don't need to bother with attributes you want to keep unchanged.
>>>>
>>>> If you want to delete the delay attribute, you can do it like this:
>>>> pcs stonith update ipmilan_node1 delay=
>>>> This will remove delay and keep all the other attributes unchanged.
>>>>
>>>> I'm not sure why this principle is not documented in pcs man page. We
>>>> can fix that, though.
>>>>
>>>> Note that specifying a stonith agent in the update command does nothing
>>>> (which is expected) and is silently ignored by pcs (which is a bug).
>>>>
>>>> Regards,
>>>> Tomas
>>>
>>> Ah, thank you (and as Andrei)!
>>>
>>> Is this behaviour not documented in 'pcs stonith help' -> update? Or was
>>> I blind and missed it?
>>>
>>
>> I think this isn't documented anywhere in pcs. It may be described in
>> Clusters from Scratch or a similar document. I think I've read it
>> somewhere, but I'm not sure where it was.
>>
>> Anyway, I put it on our todo list to get it explained in pcs help and
>> man page.
>>
>>
>> Thanks,
>> Tomas
> 
> Thanks!
> 

Well, it took four months, but it's upstream now. Hopefully this 
clarifies it
https://github.com/ClusterLabs/pcs/commit/54c4db0fdbb9caf3fbc28c2941cce89641992037
https://github.com/ClusterLabs/pcs/commit/3db16404c6b1a4fddcba7b9628c78dbad6d68d33

The fix will be included in the next versions of both supported branches 
(pcs-0.10 and pcs-0.11).

Regards,
Tomas